classification
Title: email module does not complay with RFC 2046: CRLF issue
Type: behavior Stage: resolved
Components: Library (Lib) Versions:
process
Status: closed Resolution: duplicate
Dependencies: Superseder: email.Generator does not separate headers with "\r\n"
View: 1349106
Assigned To: barry Nosy List: andrzejl, barry, dmeranda
Priority: normal Keywords:

Created on 2006-10-06 01:30 by andrzejl, last changed 2010-01-13 15:18 by r.david.murray. This issue is now closed.

Messages (2)
msg30173 - (view) Author: Andy Leszczynski (andrzejl) Date: 2006-10-06 01:30
According to rfc2046, line breaks in MIME are CRLF.
However python just
uses LF like in the following example:

from email.MIMEMultipart import MIMEMultipart
from email.MIMEText import MIMEText

msg = MIMEMultipart()
msg['Subject'] = 'Our family reunion'
msg['From'] = '...@a.b'
msg['To'] = '...@x.y'
msg.epilogue = ''

msg.attach(MIMEText('aaaaaaaaaaaaaaaaaaaaaaaa'))

print `msg.as_string()`

gives:
'Content-Type: multipart/mixed;
boundary="===============1018679223=="\nMIME-Version:
1.0\nSubject: Our
family reunion\nFrom: a...@a.b\nTo:
c...@x.y\n\n--===============1018679223==\nContent-Type:
text/plain;
charset="us-ascii"\nMIME-Version:
1.0\nContent-Transfer-Encoding:
7bit\n\naaaaaaaaaaaaaaaaaaaaaaaa\n--===============1018679223==--\n'


Found in version 2.3 and 2.4 
msg68642 - (view) Author: Deron Meranda (dmeranda) Date: 2008-06-23 17:44
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.
History
Date User Action Args
2010-01-13 15:18:54r.david.murraysetstatus: open -> closed
2010-01-12 02:07:17r.david.murraysetresolution: duplicate
superseder: email.Generator does not separate headers with "\r\n"
stage: resolved
2008-06-23 17:44:54dmerandasetnosy: + dmeranda
type: behavior
messages: + msg68642
2006-10-06 01:30:57andrzejlcreate