[issue1349106] email.Generator does not separate headers with \r\n

[Malcolm Box]

Malcolm Box malcolm@gmail.com added the comment:

David: Great to see a patch for this.

You're right of course, 8bit isn't binary - I meant binary.  The main place 
this shows up is when you're using MIME not in email (e.g. on the web), where 
binary transport is entirely possible.

This fix should mean that the MIME libraries are much more usable in non-email 
environments.  Thanks.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1349106
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1349106] email.Generators does not separates headers with \r\n

[Malcolm Box]

Malcolm Box malcolm@gmail.com added the comment:

Echoing the comment of Thomas Viehmann, the current behaviour makes it 
impossible to use this library to generate a correct multipart/mixed message 
with 7_or_8_bit encoding on Unix.

The MIME standard specifies that headers are to be CRLF terminated - this is 
independent of any lower-level transport encoding.  

Binary bodies are simply octet sequences - so may contain \n or \r characters.

The correct MIME encoding would have the headers terminated with CRLF, and the 
bodies as raw byte sequences.  However on Unix, since the headers are generated 
with \n not CRLF, you can't even post-process this (e.g. 
message.as_string().replace('\n', '\r\n') as that will screw up the binary body 
data.

The current behaviour is basically wrong and should be fixed.

--
nosy: +Malcolm.Box

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1349106
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com