[#5251] Forward multipart with qp and base64 gives incorrectly encoded MIME (sub)part in mail
| Summary | Forward multipart with qp and base64 gives incorrectly encoded MIME (sub)part in mail |
| Queue | IMP |
| Queue Version | 4.1.3 |
| Type | Bug |
| State | Duplicate |
| Priority | 2. Medium |
| Owners | |
| Requester | horde-bugs (at) conuropsis (dot) org |
| Created | 04/12/2007 (401 days ago) |
| Due | |
| Updated | 04/22/2008 (25 days ago) |
| Assigned | 04/22/2008 (25 days ago) |
| Resolved | 04/22/2008 (25 days ago) |
| Attachments | MSG_NOBUG  MSG_BUG horde-forward-fix.diff |
| Milestone | |
| Patch |
We are no longer providing bugfixes for the 4.1 branch, only security fixes.> Works for me fine on IMP 4.2. Duplicate of
Ticket 3381as 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
State ⇒ Duplicate
Works for me fine on IMP 4.2. Duplicate ofTicket 3381as previously mentioned.State ⇒ Feedback
If that fixes any problems, it'd imply that some values were not being reset correctly in some cases - or am I misinterpreting? Michael? :)New Attachment: horde-forward-fix.diff
> 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?
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.Works perfectly for me. Try IMP 4.1.4.New Attachment: MSG_NOBUG
Here is a similar, but shorter, message that does _not_ trigger the bug.New Attachment: MSG_BUG
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.
We can't do anything if we don't have the message source.I've read
bug 3381and nothing in there speaks about wrong encoding of a MIME subpart;bug 3381is 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.
State ⇒ Duplicate
I'm 99% certain this is a duplicate ofbug 3381.Summary ⇒ Forward multipart with qp and base64 gives incorrectly encoded MIME (sub)part in mail
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Type ⇒ Bug
Queue ⇒ IMP
One of my users got a mail with the following MIME structure:
1 <no description> [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 <no description> [text/plain, quoted, iso-8859-1, 5.4K]
I 2 <no description> [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