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 Deli Zhang, r.david.murray
Date 2015-11-05.17:14:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1446743653.62.0.929615586069.issue25553@psf.upfronthosting.co.za>
In-reply-to
Content
RFC 2812 says:

  Note that the first <CRLF> of this terminating sequence is also the <CRLF> that ends the final line of the data (message text)

So, smtplib is correct.  If you have a server that is not respecting this, then that server is out of compliance and there isn't anything we can do about it.

However, I don't think that is your problem.  = at the end of a line actually represents a "soft carriage return", which means one that is *eliminated* in the decoded output.  If you will read section 6.7 of rfc 2045, specifically notes (2) and (3) in the second block of numbered paragraphs, you will see that an 'ultimate' = (an = at the end of an encoded block, with or without a CRLF after it), such as you have in your sample, is illegal.  Further, the recommended recovery action if one is seen while decoding is to leave the = in the decoded output, just as you are observing happening.

So, there is no bug here except in your message :)
History
Date User Action Args
2015-11-05 17:14:13r.david.murraysetrecipients: + r.david.murray, Deli Zhang
2015-11-05 17:14:13r.david.murraysetmessageid: <1446743653.62.0.929615586069.issue25553@psf.upfronthosting.co.za>
2015-11-05 17:14:13r.david.murraylinkissue25553 messages
2015-11-05 17:14:12r.david.murraycreate