GNOME Bugzilla – Bug 784116
Preserve header's folding misbehaves for folded boundary parameter
Last modified: 2017-06-26 09:11:28 UTC
commit b9c01bd8230ec788f2e8f1cd54af1e268e5a98e9 Author: Milan Crha <mcrha@redhat.com> Date: Mon Apr 18 14:45:15 2016 +0200 Bug 235681 - Preserve header's folding Breaks the ability to process these calendar entries. Reversing this patch is sufficient to bring back the capability. The problem seems to be that lotus notes splits the Content-Type: line within the boundary directive, so on a non showing calendar item it is: ... Content-Type: multipart/mixed; boundary="=_mixed B411FBD3AB4AE8580025813E0015BEB0_=" ... --=_mixed B411FBD3AB4AE8580025813E0015BEB0_= ... Which causes the multipart mime parsers not to see the boundaries. This is a regression over the previous behaviour, so it needs fixing in the new strict header regime (perhaps by making the boundary only go through the prior parser) or reverting
Thanks for a bug report. Could you provide a whole test message, please? The thing I see from the above is that the folding is supposed to remove the leading space, while your boundary contains that space, which is basically wrong. As it can be caused by paste into the comment, a real message would be better (also for testing purposes). Thanks in advance.
Unfortunately I pasted that from a recent meeting request, which, as you can appreciate is a bit confidential. I'll see if I can get someone on notes to generate a test meeting. However, the problem is that the Content-Type is split over two lines (which I believe is legal according to RFC, so it's seen as _mixed\n B411... This is what strict header parsing causes to mismatch because it no longer exactly matches the internal email boundaries which don't have the \n
Created attachment 354344 [details] [review] Fix for the header parser to ignore newlines This is what I think is the proper fix. I don't believe it's ever proper not to unfold newlines when parsing headers, so this adds global code to do that. It fixes my lotus notes problem without reversing bug #235681
Thanks for the patch. I tried to create a similar test message, with which I've been able to reproduce the issue. I do not know whether it's exactly the same content as Lotus would generate, but let's hope it is (as I can reproduce). My initial idea was to add an unfold() call for the Content-Type header, but your change works too and it even fixes an import of such formatted message (without the patch, the last boundary is doubled, with added \n in it, which is wrong). Thus I took your patch and added it into the sources: Created commit ca2605a in eds master (3.25.4+) Created commit 357a36c in eds gnome-3-24 (3.24.4+)