This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients r.david.murray
Date 2013-03-20.20:48:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
If an SMTP server returns an error code and then closes the connection, smtplib will attempt to send an RSET command, which will then raise a socket error, which smtplib turns into a ServerDisconnectedError, thereby loosing the information about what error code the server actually returned.  While (except for code 421, as noted in issue 5713) a server doing this is technically out of spec with the RFC, it is a reality of the internet that it happens, and smtplib should handle it correctly.
Since the RSET is just to get the protocol back to a known starting state after an error, I believe the fix is to have an internal _rset method that wraps the RSET call in a try/except and just ignores any ServerDiscoonected error.  The library would then call this internally instead of the public API method.  If the library client continues on after the error code it gets back from calling an smtplib method that results in the server closing the connection, it will get the ServerDisconnected error the next time it tries to send a command to the server.  Thus the behavior change introduced here is just to allow commands that end with server disconnects to return an error code instead of an (otherwise mysterious and quite possibly currently-mishandled) ServerDisconnected error.  Since any existing code will already need to handle errors from commands sent to servers that *don't* disconnect, I believe that this is a safe fix from a backward compatibility standpoint.
Date User Action Args
2013-03-20 20:48:30r.david.murraysetrecipients: + r.david.murray
2013-03-20 20:48:30r.david.murraysetmessageid: <>
2013-03-20 20:48:30r.david.murraylinkissue17498 messages
2013-03-20 20:48:29r.david.murraycreate