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

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

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

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

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.

Here is a similar, but shorter, message that does _not_ trigger the 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 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.

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

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

1 <no description>                           [multipa/Alternativ, 7bit, 9.0K]

2 &#32;&#9500;&#9472;>Message in clear text           [text/plain, 
quoted, us-ascii, 4.8K]

3 &#32;&#9492;&#9472;>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 &#32;&#9500;&#9472;>Message in clear text       
[text/plain, quoted, iso-8859-1, 4.8K]

   I     4 &#32;&#9492;&#9472;>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