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 anadelonbrin
Recipients
Date 2003-04-20.02:38:38
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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)."
History
Date User Action Args
2007-08-23 16:06:39adminlinkissue724459 messages
2007-08-23 16:06:39admincreate