[Spambayes] Email package and the CRLF pair
T.A.Meyer at massey.ac.nz
Sat Apr 19 13:43:49 EDT 2003
> Not an expert, but I'll do my best...
Well, your comments matched those of *the* expert, so that's not bad!
> \n is LF not CR. You nearly had me confused with that...
Whoops. So it is. (you see, this is why you have both, for confused
people like me ;)
> Interesting. Does it say anything about line terminators in
> the body? It probably should, as email is a pure-text medium,
> so you should be considering line termination for the whole
> message, not just the headers.
I hadn't bothered to look that far, but yes it does. It (RFC2822) says:
"CR and LF MUST only occur together as CRLF; they MUST NOT appear
independently in the body."
> For example, is the following valid? (Ignoring issues of required
> Subject: A Test[CR][LF]
> From: Me <my/email at my.computer>[CR][LF]
> Now we start to get nasty[LF]
> Let's mix things up completely[CR][LF]
> And a Mac variation, just for fun[CR]
> So how does this look?[CR][LF]
This is a really odd one.[LF][CR]
Is also not valid.
> Interestingly, I can't see anything equivalent in imaplib.py.
> So maybe it's best argued as a bug in imaplib, rather than in
> the email package. (If the IMAP protocol mandates CRLF, then
> imaplib should ensure that rather than making client code -
> which generally uses \n internally - care about it).
This is what Barry argued as well, so this is what it was submitted as.
The way I see it, the IMAP protocol mandates RFC822, and the email
package implements RFC822, so it's the email package's job. However, I
guess the email package really does more than that, and all the
arguments Barry put forth make sense.
> For a workaround in client code, if you want to force CRLF in
> the message string, do
> This is a bit more rigorous than a simple str.replace("\n", "\r\n").
I thought that it could be a bit better, but I'm the first to admit that
I'm weak with regex. Thanks for that, I'll switch what we use to this.
More information about the Spambayes