R. David Murray added the comment:
Ah, yes, the problem is more subtle than I thought.
The design here is that we should be starting with the largest lexical unit,
seeing if that fits on the current line, or a line by itself, and if so, using
that, and if not, move down to the next smaller l
Andrei Kulakov added the comment:
I've looked into this and it seems to be somewhat intentional, as can be seen
in this test case for example:
test_headerregistry.py", line 1725, in test_fold_address_list
+ To: "Theodore H. Perfect" ,
+ "My address is very long because my name is long" ,
+
R. David Murray added the comment:
Parsing and newlines have nothing to do with this bug, actually. I don't think
your foldfix post-processing is going to do what you want in the general case.
The source of the bug here is in the folding algorithm in _header_value_parser.
It has checks to
Mike Glover added the comment:
Further research shows that email.parser.Parser is not handling the affected
lines correctly -- the leading '\n ' is not being stripped from the header
value.
Attached is the (ugly, worksforme) function I'm using to workaround this problem
--
Added fil
New submission from Mike Glover :
The attached file demonstrates the incorrect folding behavior I'm seeing.
Header lines of a certain total length get folded after the colon following the
header name, which is not valid RFC. Slightly longer or shorter lines are
folded correctly.
Interestin
