Tickets :: Comment on [#5251] Forward multipart with qp and base64 gives incorrectly encoded MIME (sub)part in mail

* Your Email Address
* Spam protection	Enter the letters below: \ /.__ .___\ /.___. >< [ __[__ >< \| / \[_./[___/ \ \|
Comment	> 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.
Attachment
Watch this ticket

Saved Queries