This follows from recent discussion on the spambayes 
mailing list (some of which was also on the mimelib-
devel list) about what character(s) should be used for 
line endings internally and when transmitted.  There is a 
consensus (I think) that the platform/language specific 
character(s) should be used internally, but any module 
that transmits the date should be responsible for 
converting this to the appropriate character(s) - for 
RFC2822/822 this means that all line endings *must* be 
\r\n.

smtplib currently does this, but imaplib doesn't (a bug 
has been posted about this).

To help people understand what the rules are, it would 
be nice if documentation could be added about this - 
especially for anyone developing a new module (like 
smtplib or imaplib) that transmits the data.  The 
following is from a post to the spambayes list from Paul 
Moore, which sounds good to me.  (Where it gets added 
is your problem ;)

"As a general set of rules (which aren't stated anywhere) 
it's probably fair to say that:

   1. Modules which manipulate internet-format data (like 
email) should work with line terminators of \n internally 
(just like Python strings do).
   2. Modules which transmit files across TCP/IP should 
canonicalise any form of line ending to CRLF.
   3. Modules which present data *received* from TCP/IP 
(like POP3) should convert data to \n line endings before 
returning it to the program.
   4. Reading from the filesystem should be handled like 
(3), and should support files opened in text or binary 
modes (or universal newline mode in Python 2.3)
   5. Writing to the filesystem should be done by 
assuming the data uses \n internally (the above rules 
make this true) and writing either in binary format (which 
leaves LFs in the files, ie Unix format) or in text format 
(which converts the \n characters to the platform native 
newline sequence)."

Logged In: YES 
user_id=12800

Self-assigning

Sorry this slipped thru the cracks so long. RDM is revamping email, most likely for 3.3, and will consider open issues in doing so.

These guidelines need to be revamped for Python3.  The place it should go is the developer docs, which I believe will soon be moved into the main documentation tree.

It's not actually clear what the guidelines should be at this point.  We haven't really finished working through the consequences of the bytes/string separation for the standard library modules that deal with bytes-on-the-wire.