#142 multipart uses wrong Content-Transfer-Encoding

[Carlos Hanson]

After using the HTML Mail plugin, a
multipart/alternative message is created to hold the
text/plain and the text/html portions of the email.
Deliver.class.php adds "Content-Transfer-Encoding:
base64" to the section.

This causes a problem when passed through Anomy
Sanitizer. Both the plain and html portions of the
multipart/alternative section become unreadable.

The following is from RFC 2045:

If an entity is of type "multipart" the
Content-Transfer-Encoding is not permitted to have any
value other than "7bit", "8bit" or "binary".

Attached is a patch for SquirrelMail 1.4.6. However,
the same section of code can be added to 1.4.4.

I use the following:

Debian Sarge
SquirrelMail 1.4.4
Apache 1.3.33
PHP 4.3.10

Carlos Hanson

[Thijs Kinkhorst]

Logged In: YES
user_id=285765

Thanks for the patch! I'm wondering however whether it would
be ok to entirely leave the header out or if we should set
it to the 'right'(?) value?

[Carlos Hanson]

Logged In: YES
user_id=184068

As a comparison, Mozilla Thunderbird does not put a
Content-Transer-Encoding for the multipart/alternative. And
it uses 7bit for the text parts rather than the 8bit that
SquirrelMail uses.

I think, given that each part of the multipart/alternative
section has its own Content-Transfer-Encoding, that leaving
out the header entirely is fine. But it may only be fine
for this example.

Carlos

[Thijs Kinkhorst]

Logged In: YES
user_id=285765

Marc, can you comment on this, since you created that code?

[Carlos Hanson]

Patch to test if mime_header is multipart (corrected)

[Marc Groot Koerkamp]

Logged In: YES
user_id=476981

Isn't this a bug in the html editor plugin?

[Roberto Piola]

Logged In: YES
user_id=2107494
Originator: NO

I had some similar problem when installing html_mail on 1.4.3a: at least one email client choked upon receiving a multipart/alternative header with a specified encoding. leaving the Content-type-encoding part out of the "Content-type: multipart/alternative" was effective in solving the problem (BTW: the MUA at hand was an old version of thunderbird, customized and recompiled by the user).

By the way, SquirrelMail 1.4.15 incorporates your patch, so I wonder why the tracker issue is still open.