The GNU Mailing List manager. https://git.neuromancer.sk/mailman.git/atom/Mailman/pythonlib/smtplib.py?h=pluggable-components 2000-12-26T22:59:08Z 2000-12-26T22:59:08Z bwarsaw 2000-12-26T22:59:08Z urn:sha1:53e4eac33399f9569fda00ddd8cba7ead504a557 2000-10-31T16:40:10Z bwarsaw 2000-10-31T16:40:10Z urn:sha1:fa28f0052adffd60e14dce4197126a76ffab089b connection fails with a socket.error, the file descriptors are reclaimed. 2000-09-11T21:20:28Z bwarsaw 2000-09-11T21:20:28Z urn:sha1:c82b4c37ac22b72e1fda6847cffca048160ca100 partial socket writes. This should fix bug #101475. 2000-08-23T20:35:52Z bwarsaw 2000-08-23T20:35:52Z urn:sha1:be0ab6392ae86f413db2a742e8644f7b45d0b5b3 names. 2000-07-06T16:56:57Z bwarsaw 2000-07-06T16:56:57Z urn:sha1:54e275cf11f7ac021668f3892a6b16e0d3314e1d 1999-11-28T17:11:06Z bwarsaw 1999-11-28T17:11:06Z urn:sha1:02d53b2445aff540d0f856f099c20b160ea659ba 1999-10-22T13:09:20Z guido 1999-10-22T13:09:20Z urn:sha1:a791a0ecdea2a17a8ac2c4a744af5beb7fa0deb7 keep whatever gethostname() returns. After a suggestion by Doug Wyatt. 1999-06-09T15:13:10Z guido 1999-06-09T15:13:10Z urn:sha1:6cd80f65a5f2d0bc9e47fc72b932ada994b207e6 I've found two places where smtplib.py sends an extra trailing space on command lines to the SMTP server. I don't know if this ever causes any problems, but I'd prefer to be on the safe side. The enclosed patch removes the extra space. 1999-04-21T16:52:20Z guido 1999-04-21T16:52:20Z urn:sha1:666f106b282b39b1c456f4afc18670a6563b41a7 Two problems: The SMTPRecipientsRefused class should not inherit SMTPResponseException, since it doesn't provide the smtp_code and smtp_error attributes. My patch for not adding an extra CRLF was apparently forgotten. The enclosed patch fixes these two problems. 1999-04-07T15:03:39Z guido 1999-04-07T15:03:39Z urn:sha1:7ce512fd70a64eb7cf9563bb31dd4291a44254dd Per writes: """ The application where Signum Support uses smtplib needs to be able to report good error messages to the user when sending email fails. To help in diagnosing problems it is useful to be able to report the entire message sent by the server, not only the SMTP error code of the offending command. A lot of the functions in sendmail.py unfortunately discards the message, leaving only the code. The enclosed patch fixes that problem. The enclosed patch also introduces a base class for exceptions that include an SMTP error code and error message, and make the code and message available on separate attributes, so that surrounding code can deal with them in whatever way it sees fit. I've also added some documentation to the exception classes. The constructor will now raise an exception if it cannot connect to the SMTP server. The data() method will raise an SMTPDataError if it doesn't receive the expected 354 code in the middle of the exchange. According to section 5.2.10 of RFC 1123 a smtp client must accept "any text, including no text at all" after the error code. If the response of a HELO command contains no text self.helo_resp will be set to the empty string (""). The patch fixes the test in the sendmail() method so that helo_resp is tested against None; if it has the empty string as value the sendmail() method would invoke the helo() method again. The code no longer accepts a -1 reply from the ehlo() method in sendmail(). [Text about removing SMTPRecipientsRefused deleted --GvR] """ and also: """ smtplib.py appends an extra blank line to the outgoing mail if the `msg' argument to the sendmail method already contains a trailing newline. This patch should fix the problem. """ The Dragon writes: """ Mostly I just re-added the SMTPRecipientsRefused exception (the exeption object now has the appropriate info in it ) [Per had removed this in his patch --GvR] and tweaked the behavior of the sendmail method whence it throws the newly added SMTPHeloException (it was closing the connection, which it shouldn't. whatever catches the exception should do that. ) I pondered the change of the return values to tuples all around, and after some thinking I decided that regularizing the return values was too much of the Right Thing (tm) to not do. My one concern is that code expecting an integer & getting a tuple may fail silently. (i.e. if it's doing : x.somemethod() >= 400: expecting an integer, the expression will always be true if it gets a tuple instead. ) However, most smtplib code I've seen only really uses the sendmail() method, so this wouldn't bother it. Usually code I've seen that calls the other methods usually only calls helo() and ehlo() for doing ESMTP, a feature which was not in the smtplib included with 1.5.1, and thus I would think not much code uses it yet. """