| Summary: | [PATCH] Non RFC2047 conformant encoded-words | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | Paweł Sakowski <pawel> |
| Component: | mime | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED UNMAINTAINED | ||
| Severity: | normal | CC: | chris, christophe, lemma |
| Priority: | NOR | Keywords: | triaged |
| Version: | SVN trunk (KDE 4) | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Patch | ||
I just have to add that in case of a comment there must be no linear-white-space between the encoded-word and the comment-closing parentheses. In the above case the closing parantheses has to be encoded as part of the second encoded word. Apparently KMail doesn't differentiate between unstructured and structured field bodies. Indeed it seems that KMail seems to ignore syntax when applying MIME encoded word decoding. The problem is explained/analyzed very well in the following usenet-post: <http://groups.google.com/group/comp.mail.pine/msg/f4f8bf9036326989>. (Remarks about KMail at the very end.) I copied the subject line given above, and sent myself an email using KMail 1.10.1. The received copy of the email shows the decoded text. Still reproducible on trunk r887937. Created attachment 28778 [details]
Patch
This should fix it.
IMHO this patch is a good start, but I think adding an "unstructured" parameter to encodeRFC2047String() is going in the wrong direction. Why? Structured headers should be escaped piece by piece, not as a whole string. For example, consider this (unescaped) From: header: From: Chris <<ク>> Heath <me@example.com> The first 2 "<" must be escaped, but the third must not. encodeRFC2047String() can't know that. Fix the callers of encodeRFC2047String() instead. Thank you for taking the time to file a bug report. KMail2 was released in 2011, and the entire code base went through significant changes. We are currently in the process of porting to Qt5 and KF5. It is unlikely that these bugs are still valid in KMail2. We welcome you to try out KMail 2 with the KDE 4.14 release and give your feedback. |
Version: KMail/1.5 (using KDE KDE 3.1.4) Installed from: I Don't Know OS: Linux I've received an e-mail sent by KMail/1.5 which included the following Subject line: Subject: Re: wxWindows (Re: =?iso-8859-2?q?Troch=EA?= =?iso-8859-2?q?=20zwolni=E6?=) My mailer (Evolution 1.4.5) refused to interpret the second encoded-word since it violates RFC 2047 section 5.(1): it isn't separated from the closing parentheses with a linear-white-space.