#163 header folding breaks attached files with QP encoded names


Under certain circumstances, files attached to emails sent from SquirrelMail contain headers which are folded in a way that causes the receiving mail client to mangle the file name.

When the total length of the encoded file name is about 90 characters, SquirrelMail puts a line break about 1-2 characters from the end, which breaks the file extension.

Error occurs in both 1.4.8 and 1.4.9a.

To reproduce:
* Create a file with the following file name:
12 blablabla bläb bläblabl bla bla blablab blöblablåbla 1234.txt
(The swedish characters åäö are used here, but other characters that are QP encoded will probably trigger the error.)
Another example:
12 blablabla bléb blíblabl bla bla blablab bláblablúbla 1234.txt

* Attach the file to an email and send the email.

* Open the sent email or view the received email in SquirrelMail or Mozilla Thunderbird. Both clients will display the file name as
"12 blablabla bläb bläblabl bla bla blablab blöblablåbla 1234.tx t" (note the space inside "txt")

This is what the relevant part of the email source looks like:

Content-Type: text/plain; name="12 blablabla
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="12 blablabla

dummy content

The problem is probably located in the foldLine() function in class/deliver/Deliver.php


  • Tomas Kuliavas

    Tomas Kuliavas - 2007-05-13

    Logged In: YES
    Originator: NO

    nope. problem is in encodeHeader() function. functions/mime.php.

    SquirrelMail encodeHeader() function splits encoded header when it reaches rfc2822 recommended header line length limit and turns off encoding on next line, because next line is not in 8bit. rfc2047 '6.2. Display of 'encoded-word's'. code must keep next line encoded.

    It is not foldLine() issue. Make sure that you have mbstring support in php, switch to utf-8, create new email with same attachment and recheck attachment name. If SquirrelMail encodes header in B encoding, space is not added. encodeHeader() and japanese extra code make smart encoding decisions. encodeHeaderBase64() does not do it. There is only one incorrect encodeHeaderBase64() related decision in encodeHeader() function. sq_is8bit() check. It might break things in 7bit charsets, but stock SquirrelMail uses them only in Japanese and Japanese have own xtra_code hooks in encodeHeader.

    Duplicate bug report. See 870359 - encodeHeader does not work correctly with long headers


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks