#142 multipart uses wrong Content-Transfer-Encoding


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


  • Carlos Hanson

    Carlos Hanson - 2006-04-04
    • summary: multipart uses wrong Content-Transer-Encoding --> multipart uses wrong Content-Tranfser-Encoding
  • Carlos Hanson

    Carlos Hanson - 2006-04-04
    • summary: multipart uses wrong Content-Tranfser-Encoding --> multipart uses wrong Content-Transfer-Encoding
  • Thijs Kinkhorst

    Thijs Kinkhorst - 2006-04-05

    Logged In: YES

    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

    Carlos Hanson - 2006-04-05

    Logged In: YES

    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.


  • Marc Groot Koerkamp

    • assigned_to: nobody --> stekkel
  • Thijs Kinkhorst

    Thijs Kinkhorst - 2006-04-18

    Logged In: YES

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

  • Carlos Hanson

    Carlos Hanson - 2006-04-18

    Patch to test if mime_header is multipart (corrected)

  • Marc Groot Koerkamp

    • labels: 102906 -->
  • Marc Groot Koerkamp

    Logged In: YES

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

  • Roberto Piola

    Roberto Piola - 2008-08-21

    Logged In: YES
    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.


Log in to post a comment.