https://bugzilla.novell.com/show_bug.cgi?id=469222 Marcus Meissner changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|bnc-team-screening@forge.pr |werner@novell.com |ovo.novell.com | -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=469222 User odabrunz@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=469222#c2 Olaf Dabrunz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW Info Provider|odabrunz@novell.com | --- Comment #2 from Olaf Dabrunz 2009-01-26 10:36:30 MST --- The patch should be changed. Done and testing. Rationale: The original patch removes the folding CRLF (or LF in the internal representation) as well as the leading character (whitespace) on the continuation line. This was done as many mail programs at that time constructed folding by inserting CRLF<TAB> or CRLF<SP>, rather than just CRLF. This was permitted by the wording in RFC822 (section 3.1.1), but it introduced the problem that unfolding was unable to reliably restore the original spacing. Nowadays more clients seem to follow RFC2822. The wording there (section 2.2.3) makes clear that only a CRLF may be inserted to fold a line. This enables unfolding to restore the original spacing. Expecting RFC2822-compliant mail clients seems to be the right choice today. The downside is that mails created with older clients may have too little whitespace removed on a continuation line. But that is becoming seldom now, and it should be fixed by upgrading or replacing these clients. Will submit the updated patch as soon as I am done testing. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=469222 User odabrunz@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=469222#c3 Olaf Dabrunz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED --- Comment #3 from Olaf Dabrunz 2009-01-26 14:20:29 MST --- Tested on my workstation (10.3). Submitted to STABLE and 11.1. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=469222 Olaf Dabrunz changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO Info Provider| |coolo@novell.com -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=469222 Stephan Kulow changed: What |Removed |Added ---------------------------------------------------------------------------- Info Provider|coolo@novell.com |maint-coord@suse.de -- 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.

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 2009-01-27 06:34:16 MST --- (In reply to comment #6)

(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.

https://bugzilla.novell.com/show_bug.cgi?id=469222 User werner@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=469222#c12 Dr. Werner Fink changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED Info Provider|odabrunz@novell.com | Resolution| |FIXED --- Comment #12 from Dr. Werner Fink 2009-02-10 11:19:35 MST --- also submitted to SLES11 -- 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.