I don't believe this is fixed in 2.1.2 or 2.2, but
haven't checked.

The code in rfc822.Message.readheaders incorrectly
unfolds long message headers. The relevant information
from rfc2822 is in section 2.2.3. In short:

"""
The process of moving from this folded multiple-line
representation of a header field to its single line
representation is called "unfolding". Unfolding is
accomplished by simply removing any CRLF that is
immediately followed by WSP.  Each header field should
be treated in its unfolded form for further syntactic
and semantic evaluation.
"""

This means that the code in readheaders:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = (self.dict[headerseen] + "\n " +
line.strip())
                self.dict[headerseen] = x.strip()
                continue

should be:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = self.dict[headerseen] + line
                self.dict[headerseen] = x.strip()
                continue

ie. no stripping of the leading whitespace and no
adding the newline.

Logged In: YES 
user_id=6380

Richard, have you found a situation where it matters? I
thought that usually the next phase calls for normalizing
whitespace by squashing repeated spaces/tabs and removing
them from front and back.

Logged In: YES 
user_id=6405

Yes, we had someone submit a bug report on the roundup 
users mailing list because someone had sent a message to 
the roundup mail gateway which was split. The client was 
extra-specially broken, since it split in the middle of a 
word (which is not to spec), but the more general case of 
folding on whitespace will cause roundup problems since I 
hadn't expected there to be any newlines in the header.

I can modify roundup to strip out the newline, but it'd be 
nice to have rfc822.Message not put it in there...

Logged In: YES 
user_id=21627

Even though it might not matter, I don't think changing it
would hurt, either, and the change brings it definitely
closer to following the word of RFC 2822. 

If no case is brought forward where it matters, fixing it
for 2.3 alone should be sufficient.

Logged In: YES 
user_id=12800

There is some value in not unfolding long lines by default.
 FWIW, the email package also retains the line breaks for
such multi-line headers.  The advantage to retaining this is
that message input/output can be idempotent (i.e. you get
the same thing in as you get out).  This can be useful when
using the message to generate a hash value, and for other
user-friendly reasons.

That being said, there is also some use in providing a way
to return the unfolded line.  I don't see a lot of benefit
in adding such a feature to the rfc822 module, but I could
see adding it to the email package.  Specifically, I would
propose to add it to the email.Header.Header class, either
as a separate method (e.g. Header.unfold()) or as a default
argument to the Header.encode() method (e.g.
Header.encode(self, unfold=0)).

If we did the latter, then I'd change Header.__str__() to
call .encode(unfold=1).

Assigning to Ben to get his feedback.  Ben, feel free to
comment and re-assign this bug to me.

Logged In: YES 
user_id=6405

Hurm. This issue has been lost to the void, but it's as valid today as it 
ever was. I've just had another user of Roundup run into the same thing: 
 
 RE: [issue51] Mails being delayed 
[assignedto=stuartm;priority=medium]  
 
(that should be one long line) became 
 
 RE: [issue51] Mails being delayed [assignedto=stuartm;priority=me 
dium] 
 
when sent by Outlook. Note that the current code reconstructs that line 
as "me\ndium" which is about as wrong as it can get, as there's no way 
for my code to determine whether that *should* be "me dium" or 
"medium" since the other whitespace has been stripped (so just stripping 
out the newline, as my code currently does, doesn't help). 
 
I stand by my original post, requesting that the code be fixed as stated. 
 

Logged In: YES 
user_id=12800

Since this was never addressed in the email package either,
perhaps you'd like to bring it up in the email-sig?

Logged In: YES 
user_id=6405

OK, I've sent a message, but I don't have the time to sign up to the list. 

Is this still an issue?  No activity since 2003-11.

How about this patch? It basically does

  self.dict[headerseen] += line.rstrip()

which should be what the RFC prescribes, maintaining the invariant that
the dict values don't end in whitespace.

I haven't written a test for this behavior.

Barry, what do you think of this patch?  How does the email package
handle this case?

This issue still seems to be present in Python 2.5's email module.

feedparser.py line 444-445 says:

# XXX reconsider the joining of folded lines
lhdr = EMPTYSTRING.join(lastvalue)[:-1].rstrip('\r\n')

I think that should be something like:
lhdr = EMPTYSTRING.join(ln.rstrip('\r\n') for ln in lastvalue)[:-1])

The resulting headers still need a fair amount of massaging, though; why
not just use Header instances for the headers?

The source lines mentioned in this issue have not been changed in trunk,
and the feedparser line has not been changed in py3k as of r71355
(rfc822 no longer exists, so I'm not sure if the replacement code in
py3k has the issue or not).

Confirmed still an issue in py3k by using the email subject line from msg8771 and adding two extra test cases to TestParsers got two failures.  Tried several variations of the patch from msg71573 (in the original the parantheses are unbalanced) and pushed the number of failures to over 80.  I've attached a patch against the unit test file, note that the comments will need changing.

The email package no longer strips the leading whitespace.  It doesn't unfold the headers, but changing that at this stage has untenable consequences.

However, the email package in 3.3 will have a provisional API that will provide the correct unfolding of headers in an easy to use way.  So I'm closing this in favor of the issue where I will add that API.