Bug 108939

Summary:	forwarded messages uses wrong encondings (base64 or quoted-printable) for message/rfc822 (against RFC 1521)
Product:	[Unmaintained] kmail	Reporter:	Jacek Konieczny <jajcus>
Component:	general	Assignee:	Till Adam <adam>
Status:	RESOLVED FIXED
Severity:	major	CC:	avbidder+kde, pfeiffer, pradeepto, smiejek
Priority:	HI
Version:	1.9.4
Target Milestone:	---
Platform:	unspecified
OS:	All
Latest Commit:		Version Fixed In:
Sentry Crash Report:
Attachments:	The original message (gzipped) which is encoded incorrectly whe forwarded The incorrectly forwarded message (gzipped)

Description Jacek Konieczny 2005-07-11 19:18:58 UTC

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.

Comment 1 Thiago Macieira 2005-07-12 03:31:50 UTC

I cannot confirm, trunk 430645. Can you attach a message that, when forwarded, gets encoded in base64?

Comment 2 Jacek Konieczny 2005-07-12 08:52:11 UTC

Created attachment 11775 [details]
The original message (gzipped) which is encoded incorrectly whe forwarded

Comment 3 Jacek Konieczny 2005-07-12 08:54:01 UTC

Created attachment 11776 [details]
The incorrectly forwarded message (gzipped)

Comment 4 Thiago Macieira 2005-07-12 13:36:11 UTC

I can reproduce this on KMail/Kontact 430645. Forwarding the message in attachment 11775 [details] makes it go encoded in Base64.

Comment 5 Thiago Macieira 2005-07-22 13:42:42 UTC

*** Bug 109414 has been marked as a duplicate of this bug. ***

Comment 6 bruce.lilly 2005-07-22 14:27:17 UTC

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.

Comment 7 Carsten Pfeiffer 2005-11-01 19:01:06 UTC

*** Bug 66318 has been marked as a duplicate of this bug. ***

Comment 8 bruce.lilly 2006-09-19 02:06:16 UTC

Bug remains in Kmail 1.9.4 / KDE 3.5.4

Comment 9 Bernhard E. Reiter 2006-09-25 11:38:16 UTC

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

Comment 10 Till Adam 2006-09-25 19:08:11 UTC

Bug is fixed in proko2 now, I'll cross port.

Comment 11 Bernhard E. Reiter 2007-02-20 15:41:27 UTC

Till, is the fix in already?

Comment 12 Bernhard E. Reiter 2007-02-20 15:50:33 UTC

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.

Comment 13 Allen Winter 2007-02-20 21:45:42 UTC

I looked into this earlier today.
Current status: pradeepto (KDAB employee) will port this for us into the main 3.5 branch.

Comment 14 Pradeepto K. Bhattacharya 2007-03-08 11:02:57 UTC

Revision 640496. Forward ported Till's proko2 implementation to branches/3.5/kdepim.

Comment 15 Allen Winter 2007-03-09 15:33:19 UTC

Fixed.
Pradeepto ported till's proko2 implementation.

Comment 16 Bram Schoenmakers 2007-03-09 18:18:00 UTC

OK, closing the bug then.