Forward multipart with qp and base64 gives incorrectly encoded MIME (sub)part in mail

One of my users got a mail with the following MIME structure

Thu, 12 Apr 2007 16:29:57 +0000

One of my users got a mail with the following MIME structure: 1 [multipa/Alternativ, 7bit, 9.0K] 2 ├─>Message in clear text [text/plain, quoted, us-ascii, 4.8K] 3 └─>Message in HTML form [text/html, base64, iso-8859-1, 3.7K] when he forwards it, it gives a mail with the following structure, where the text of the forwarded message is in part 1 _and_ the whole forwarded message is included as a MIME part: I 1 [text/plain, quoted, iso-8859-1, 5.4K] I 2 [multipa/alternativ, 7bit, 9.0K] I 3 ├─>Message in clear text [text/plain, quoted, iso-8859-1, 4.8K] I 4 └─>Message in HTML form [text/html, quoted, iso-8859-1, 3.7K] The problem is that the contents of the subpart whose MIME headers say "text/html, quoted, iso-8859-1" is actually base64; probably the Content-Transfer-Encoding in the MIME header is the one of the previous (text/plain) subpart, but it didn't actually get converted from base64 to quoted printable. Or something like that. Actually, I find it weird that the charset and transfer-encoding are changed at all. Beginning of the erroneous part: --AGENTID00131719-=_sMcQfL3yqRNdc9lqwCKbprFWr Content-Type: text/html; charset=iso-8859-1 Content-Description: Message in HTML form Content-Disposition: inline Content-Transfer-Encoding: quoted-printable PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PEI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9NSBD

I'm 99% certain this is a duplicate of bug 3381.

Fri, 13 Apr 2007 21:47:07 +0000

I'm 99% certain this is a duplicate of bug 3381.

I've read bug 3381 and nothing in there speaks about wrong e

Sat, 14 Apr 2007 06:21:09 +0000

I've read bug 3381 and nothing in there speaks about wrong encoding of a MIME subpart; bug 3381 is about putting a copy of the text/plain part in the body of the new message and putting the MIME parts of the forwarded message in the new message. Bug reporter was arguing that one should not do both. I wasn't arguing that question, I was saying that one MIME subpart of the forwarded message ends up with a wrong content-transfer-encoding header. The result of this bug is that, when reading the new message with a MUA that will choose text/html over text/plain in a multipart/alternative (such as MS Outlook), one sees something like: PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PEI+PEZPTlQgRkFDRT0iQXJpYWwiIFNJWkU9NSBD that is the message in its base64-encoded form. The MUA won't decode it because the header doesn't say "content-tranfer-encoding: base64" as it should, but it says "content-transfer-encoding: quoted-printable". Or alternatively, it should actually be transcoded from base64 (how it was in the forwareded message) into quoted-printable. What is possible is that the fix for 3381 fixes this as a side-effect. The bug log of 3381 isn't clear on whether it is supposed to be fixed in 4.1.4 or only in HEAD. Anyway, I have installed 4.1.4, and this bug (5251) is still present.

We can't do anything if we don't have the message source.

Mon, 16 Apr 2007 23:10:11 +0000

We can't do anything if we don't have the message source.

Here is a message that triggers this bug. The bug seems t

Tue, 17 Apr 2007 07:39:13 +0000

Here is a message that triggers this bug. The bug seems to be length-related; if one puts only one "lorem ipsum" paragraph in the text/html part, then the bug is _not_ triggered.

Here is a similar, but shorter, message that does _not_ trig

Tue, 17 Apr 2007 07:41:58 +0000

Here is a similar, but shorter, message that does _not_ trigger the bug.

Works perfectly for me. Try IMP 4.1.4.

Wed, 18 Apr 2007 22:35:26 +0000

Works perfectly for me. Try IMP 4.1.4.

I upgraded to IMP 4.1.4 and still hit the bug. I haven't upg

Thu, 19 Apr 2007 06:06:18 +0000

I upgraded to IMP 4.1.4 and still hit the bug. I haven't upgraded to latest horde / php libraries etc, though. I'll try that and see whether that makes it disappear.

> I upgraded to IMP 4.1.4 and still hit the bug. I haven't u

Mon, 21 Apr 2008 16:05:44 +0000

> I upgraded to IMP 4.1.4 and still hit the bug. I haven't upgraded to > latest horde / php libraries etc, though. I'll try that and see > whether that makes it disappear. Try this simple patch, Someone more familiar with the horde code could please check for side effects?

If that fixes any problems, it'd imply that some values were

Tue, 22 Apr 2008 04:28:19 +0000

If that fixes any problems, it'd imply that some values were not being reset correctly in some cases - or am I misinterpreting? Michael? :)

Works for me fine on IMP 4.2. Duplicate of Ticket 3381 as p

Tue, 22 Apr 2008 04:54:51 +0000

Works for me fine on IMP 4.2. Duplicate of Ticket 3381 as previously mentioned.

> Works for me fine on IMP 4.2. Duplicate of Ticket 3381 as

Tue, 22 Apr 2008 17:49:05 +0000

> Works for me fine on IMP 4.2. Duplicate of Ticket 3381 as previously > mentioned. not exactly, 4.2 has a different codebase, so fixed in HEAD do not apply to 4.1.x the currently stable branch is 4.1 and debian etch still uses 4.1.3 so it's not always possible to upgrade, I suggest (if my small patch has no side effects) to apply to next 4.1.x when it will be out, tough no urgent if I understand the code, the bug will apply to all text/* attachments that are in base64 since case 'text': ... will never leave the encoding to base64

We are no longer providing bugfixes for the 4.1 branch, only

Tue, 22 Apr 2008 18:08:09 +0000

We are no longer providing bugfixes for the 4.1 branch, only security fixes.