[Spambayes] Email package and the CRLF pair

[Meyer, Tony]

> 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
> headers)
> 
>     Subject: A Test[CR][LF]
>     From: Me <my/email at my.computer>[CR][LF]
>     [CR][LF]
>     [CR][LF]
Yes.
>     Now we start to get nasty[LF]
No.
>     Let's mix things up completely[CR][LF]
Yes.
>     And a Mac variation, just for fun[CR]
No.
>     So how does this look?[CR][LF]
Yes.  This:
      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.

=Tony Meyer