https://bugzilla.novell.com/show_bug.cgi?id=469222
User odabrunz@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=469222#c7
--- Comment #7 from Olaf Dabrunz
(In reply to comment #4)
Note that unfolding in procmail is now RFC2822-compliant, but I still see continuation lines that start with an inserted <TAB> (or a <TAB> that >replaced a <SPACE>).
I think a TAB is for readability, but a continuation line will always have at
I also think it is for readability of the transmitted header.
least one leading whitespace character.
I am sorry that I have not described what this means. Here it is: The problem is that an RFC2822-compliant procmail needs to leave this "folding-<TAB>" intact when it unfolds the mail header. This means that a mail header like this: Subject: [Mutt] #3170: mutt: Attachments are automatically displayed even with 'Content-Disposition: attachment' ^ <TAB> here is transformed into this: Subject: [Mutt] #3170: mutt: Attachments are automatically displayed even with 'Content-Disposition: attachment' ^ | <TAB> here There is a <TAB> (or more) in the unfolded line which is not in the original line. That means that after unfolding has been done by formail, it is not possible to find out which <TAB>s are artefacts of the folding and which are not. I find the resulting line quite disturbing to the reader's eye. To make this more visible in the limited line width of Bugzilla, the line will look like this: Subject: [...] displayed even with 'Content-Disposition: attachment' ^ <TAB> here MUAs like mutt have the same problem during unfolding. But no MUA I have seen shows the <TAB> in the unfolded line. They chose to use an unfolding heuristic rather than comply to RFC-2822 section 2.2.3 in all cases. (Note that this unfolding heuristic is also not compliant to RFC-822 section 3.1.1. This section allowed the folding practice that lead to this problematic situation, but unfolding was defined there in an equivalent way to RFC-2822. I consider this to be a problem in RFC-822. And migrating away from this has not been addressed in RFC-2822. Not addressing this problem leads to implementations that violate the robustness principle, as they are not working with the input they get. IMHO, we would violate the robustness principle if we were simply RFC-2822-compliant.) That is why I proposed this for procmail:
We probably could implement an additional heuristic that replaces the special cases CRLF<TAB><SPACE> with <SPACE> and CRLF<TAB><OTHER> with <SPACE><OTHER>.
I should also make clear that this heuristic does not apply to CRLF<WSP>, where <WSP> is not <TAB>. A CRLF<WSP> will be unfolded to <WSP>, in compliance with RFC-2822 and RFC-822.
If we just remove the CRLF, we are in compliance with RFC-2822. Lines may only be folded where there is whitespace, and the CRLF is inserted before any whitespace.
From RFC-2822:
The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. [snip] Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP.
(Right. This is section 2.2.3 that I cited in comment #2.)
I think compliance is paramount as formail is typically used in scripts and procmail recipes on different distros, and it's important that it behaves in the same way everywhere.
I agree that (in principle) it should behave the same everywhere. The question is: is this the correct behaviour or should we change it everywhere? I would say this is in need of a migration heuristic. My point is supported by all MUAs I have seen (mutt, KMail, Thunderbird, ...), as they implement a heuristic instead and rather than being fully RFC2822-compliant. A problem is that upstream development for procmail (http://www.procmail.org/) has stopped since 2001. I do not remember if I submitted my patch to them, but I recon it will be difficult to make any change to the upstream procmail. Please also note that we have a few other changes to procmail and they did not make it upstream as well. If we could reactivate upstream, this would be possible. I have not fully researched this, but as a compromise I could try to add a command line option and/or an environment variable to procmail and formail that turns the heuristic on. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.