Part of RFC 822 ignored by email module

[Bob Kline]

On 1/20/2011 12:58 PM, Dennis Lee Bieber wrote:
>
> 	I'd first be concerned about the absence of the line ending sequence
> specified by the RFC: carriage return (CR; \r) followed by line feed
> (LF; \n).

I realized after I posted the original message that this might distract 
from the issue I'm asking about.  The module is a little sloppy about 
its own generation of CRLF tokens when it serializes messages (it leaves 
the insertion of the CR to processing further downstream), and I was 
mimicking that behavior in what I fed to the method in my example.  I 
should have avoided that problem and included the \r.  Let's pretend 
that I did: the behavior is unaffected by the absence or presence of the 
CR character.

> ...
>
> 	However, the module does appear to trim leading whitespace that
> occurs between the : and text (and the line end is considered for that
> trimming, but not any whitespace after it).

Exactly.  I'm focusing on the word "equivalent" in the RFC.  Either the 
module is going to strip leading white space from the value or it's 
not.  Returning different values for the unwrapped header, depending on 
whether wrapping was present, is failing to treat the two sequences as 
equivalent.  Logically, the processing sequence should be:

   1. Unwrap the header ("Subject:\r\n foo" becomes "Subject: foo")
   2. Trim leading white space (" foo" becomes "foo")

Ideally, the behavior of trimming the leading white space would be 
reflected documentation (but it isn't).

-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20110120/a310f854/attachment-0001.html>