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 dmeranda
Recipients andrzejl, barry, dmeranda
Date 2008-06-23.17:44:54
SpamBayes Score 0.0061601335
Marked as misclassified No
Message-id <>
Still an issue in 2.5.

This lack of conformance to the RFC is can also cause problems when
trying to use encrypted or signed email, as those activities may depend
on "canonical" line endings.  An LF rather than CR+LF can cause the
crypto to break in some cases.

This appears to be caused by the email package writing to an internal
StringIO file using the print statement, where it relies on print
outputting the end-of-line character (which will always output a LF). 
The module should instead write the eol character(s) explicitly.

To maintain backwards compatibility, it may be best if the preferred eol
character be settable on a per-message basis; which would default to the
current non-conforming behavior of LF, but which could be set to CR+LF
if strict MIME behavior is desired.
Date User Action Args
2008-06-23 17:44:56dmerandasetspambayes_score: 0.00616013 -> 0.0061601335
recipients: + dmeranda, barry, andrzejl
2008-06-23 17:44:56dmerandasetspambayes_score: 0.00616013 -> 0.00616013
messageid: <>
2008-06-23 17:44:54dmerandalinkissue1571841 messages
2008-06-23 17:44:54dmerandacreate