MIME renderer: wrong header line break with long subject? #44510
Comments
>>> from email.MIMEText import MIMEText
>>> o=MIMEText('hello')
>>> o['Subject']='1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4
5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 '
>>> o.as_string()
'Content-Type: text/plain; charset="us-ascii"\nMIME-Version: 1.0\nContent-Transf
er-Encoding: 7bit\nSubject: 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8
9 1 2 3 4 5 6 7 8\n\t9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9 \n\
nhello'
>>>The '6 7 8\n\t9 1 2 3' clashes together to 6 7 89 1 2 3 '6 7 8 \n\t9 1 2 3' ? as there is also the space preserved in |
|
Tokio, I'm not so sure about adding that extra space. I tested all the mail readers at my disposal on Linux and OSX. I don't have any Windows machines available so I couldn't test Outlook or OE. (If you have them, please indicate what they do in a comment here!) Here's what I found: OSX: Linux So anyway, afaict, the extra space is not appropriate for any of the non-Windows mail readers. |
|
Whoops, this wasn't supposed to be a response to Tokio, but instead the OP. |
|
What would be the RFC definition for a correct auto-line break in a (subject) mail header line? |
|
Quoting RFC2822 section 2.2.3 <ftp://ftp.rfc-editor.org/in-notes/rfc2822.txt\>: """The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: can be represented as: [...]Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP.""" That is, folding is done by inserting ONLY the sequence CRLF before any folding whitespace. When the header is interpreted, the whitespace is NOT removed, only the CRLF. The posted Subject header should become "Subject: 1 2 3...7 8\n\r 9 1 2...' I think this is a bug in the email.header.Header class; its __init__ says, about the continuation_ws argument: "[it] must be RFC 2822 compliant folding whitespace (usually either a space or a hard tab) which will be prepended to continuation lines.". Folding does not involve *prepending* any whitespace, just inserting CRLF right before *existing* whitespace. Note that this is wrong even for the old RFC 822 (with slightly different rules for line folding.) |
|
the bug appears to be quite frequent now (once one knows it :-) ). Possibly for the same reason one sees this kind of subject alteration by one space often on the usenet. |
|
The problem occurs, when you are using strings, not when you use >>> from email.MIMEText import MIMEText
>>> msg = MIMEText("Just a test.")
>>> msg["Subject"] = "foo "*22
>>> print msg.as_string()
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
foo foo foo foo foo Just a test.
Tab as the whitespace character is no problem for most email clients. But When using the Header class you get the following >>> from email.MIMEText import MIMEText
>>> from email.header import Header
>>> msg = MIMEText("Just a test.")
>>> msg["Subject"] = Header("foo "*22)
>>> print msg.as_string()
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo
foo foo foo Just a test.
The last message shows up in Outlook correctly. |
|
Just struck this myself, found Andi's solution to work. Constructing the header using email.header stops it from breaking the Suggest the documentation example page be updated to use header() in (I can only guess as to they why of this, it seems not to hang the |
|
Argg, yes, as Andi explained it's the tab (not sure how I missed that on |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: