File "smtplib.pyc", line 690, in sendmail
  File "smtplib.pyc", line 445, in rset
  File "smtplib.pyc", line 370, in docmd
  File "smtplib.pyc", line 344, in getreply
  File "smtplib.pyc", line 159, in readline
sslerror: (8, 'EOF occurred in violation of protocol')

traced from a py2.3 - yet unchanged.  

=> hides original error SMTPDataError. such
SMTPDataError may have forced a disconnect of server. 

patch for py2.3,py2.4,..

( I have this patch in my MUST-DO-PATCHes after any
Python installation. )

--

the patch passes on any error in this rset() location.
it also patches a error in PLAIN authentication

could cleanly catch socket.sslerror / socket.error /
EnvironmentError, yet ssl not always there ... 
rset() is tested otherwise, so the nacked except is ok?

(there should maybe be special a common base Exception
class "IOBaseError" for :   EnvironmentError(IOError,
OSError),  EOFError, socket.error, socket.sslerror,
ftplib.all_errors, etc.  Nice as it and not all IO
sublibs have to be imported to catch such errors.)

---

the same problem is with smtp.quit() on many SSL'ed
connections (without any other errors occuring): a
final socket.sslerror is raised during quit(). 
There may be a problem in the termination code of
ssl-FakeSockets or ssl.c . Or the same type of error
catch (on IOBaseError) should be applied. I am not sure
 - in my apps I (must) catch on smtp.quit() generally. 

(Compare also bug #978833 / shutdown(2)-remedy in
httplib's SSL FakeSocket - this shutdown(2) remedy
patch of #978833 I still have it on my MUST list
(py2.3/py2.4 installations), otherwise this FakeSocket
doesn't close fully in a FTPS application (where
termination on data channel is crucial for getting
response on the control channel) - and most likely puts
tremendous connection load on HTTPS servers because of
stale unterminated HTTPS connections while the bug may
not be obvious in casual usage. I'm not completely
clear about the nature of this error. Thus, what I say
is based on trial-and-error.

-robert