Version: 1.7.2 (using KDE KDE 3.3.2) Installed from: Mandriva RPMs OS: Linux When a message is forwarded as an attachement then it is sent with Content-Type: message/rfc822. That is ok, but there are some restrictions for that content type. RFC 1521, section 7.3. states: As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for messages or parts of type "message". Even stronger restrictions apply to the subtypes "message/partial" and "message/external-body", as specified below. The message header fields are always US-ASCII in any case, and data within the body can still be encoded, in which case the Content-Transfer-Encoding header field in the encapsulated message will reflect this. KMail sometimes, incorrectly uses Base64 encoding for message/rfc822 attachements. Such messages may be rejected by standard-compliant filtering software, like amavisd-ng.
I cannot confirm, trunk 430645. Can you attach a message that, when forwarded, gets encoded in base64?
Created attachment 11775 [details] The original message (gzipped) which is encoded incorrectly whe forwarded
Created attachment 11776 [details] The incorrectly forwarded message (gzipped)
I can reproduce this on KMail/Kontact 430645. Forwarding the message in attachment 11775 [details] makes it go encoded in Base64.
*** Bug 109414 has been marked as a duplicate of this bug. ***
RFC 1521 has been obsolete for more than 8 years, having been obsoleted by RFCs 2045 and 2046. The restriction on encoding of course remains. The problem is not specific to that newfangled "Mandriva"; it appears in SuSE rpms also. Nor is it limited to 1.7.x; it remains in 1.8.1. The problem appears to have been reported as bug 1492, version 1.0.21 (marked CLOSED and FIXED). It also is exhibited as quoted-printable encoding rather than base64. Another example is attached to bug 109414.
*** Bug 66318 has been marked as a duplicate of this bug. ***
Bug remains in Kmail 1.9.4 / KDE 3.5.4
Changing title to also reflect the wrong quoted-printable usage that can occur. Raising priority because this is a bug which makes KMail send out broken emails. There is a corresponding Kolab issue: https://intevation.de/roundup/kolab/issue1384
Bug is fixed in proko2 now, I'll cross port.
Till, is the fix in already?
For completeness, rfc1521 was obsoleted. Currently active as "draft standard" is rfc2045, which has 6.4. Interpretation and Use If an entity is of type "multipart" the Content-Transfer-Encoding is not permitted to have any value other than "7bit", "8bit" or "binary". Even more severe restrictions apply to some subtypes of the "message" type.
I looked into this earlier today. Current status: pradeepto (KDAB employee) will port this for us into the main 3.5 branch.
Revision 640496. Forward ported Till's proko2 implementation to branches/3.5/kdepim.
Fixed. Pradeepto ported till's proko2 implementation.
OK, closing the bug then.