#1881 Attachments decode base64 corrupt

Mike Slywka


Sorry if this has already been reported but I couldn't
find anything in the mailing list archives or on here.

I'm running squirrelmail 1.4.5-1, apache 2.0.52, php
4.3.9 and uw IMAP4rev1 2004.357.

I'm having a problem displaying primarily microsoft
attachments (word, excell ...) as well as a tar file
that I used to verify that there seemed to be a problem
with the base64 decoding. Webmail seems to be
prepending a "\n" character to the beginning of the file.

I only see the problem when I try to download and view
one of these documents from squirrelmail. If I send the
mail with the attachment from squirrelmail and read it
in another email client, I can download and view the
document fine. No matter which client I use to compose
the email with the attachment, I only have problems
viewing it from squirrelmail.

I've tried bumping up the post_max_size to 50M and
upload_max_filesize to 50M in php.ini but that didn't

I've tried several files from the CVS snapshot on the
squirrelmail homepage (version 1.4.6) specifically the
src/downloads.php file since the Changelog mentions
something about corrupted attachments being fixed in
this version. I've diffed a few of the other files in
1.4.6 with my version that seemed to make sense:
attachments_common.php and mime.php to name a few. No
luck there either.

Lastly I've tried one of the patches I found on here
that was a change to mime.php, and that didn't fix
anything for me either.

So, can someone either let me know some things I can
try or point me in the right direction please?




  • Marc Groot Koerkamp

    • status: open --> pending
  • Marc Groot Koerkamp

    Logged In: YES

    Try to disable all the plugins and put back the original
    source. This is probably caused by an extra \n after a
    closing php tag (?>).
    Did you edited your config.php file manualy?

  • Mike Slywka

    Mike Slywka - 2005-09-15
    • status: pending --> open
  • Mike Slywka

    Mike Slywka - 2005-09-15

    Logged In: YES

    I've removed all the plugins and still get the same problem.
    I restarted the webserver after removing all of the plugins
    just to make sure, even though I beleive this is unnecessary.

    I didn't edit the config.php file manually, I've just been
    using the conf.pl script to configure squirrelmail.

    Here is the list of plugins I have installed:
    1. delete_move_next
    2. squirrelspell
    3. newmail
    4. calendar
    5. translate
    6. sent_subfolders
    7. message_details
    8. abook_take
    9. filters
    10. listcommands
    11. abook_import_export
    12. squirrel_logger
    13. show_headers
    15. attachment_tnef
    16. get_uuencode

    Thanks. I'll take a look at the files in the distro and
    check that there aren't any \n characters after the closing
    tags in there.


  • Mike Slywka

    Mike Slywka - 2005-09-15

    Logged In: YES

    Well, just to rule it out, I upgraded php to 4.3.11 with no
    luck. Guess I'll go back to looking for trailing \n's in the
    php files ...


  • Mike Slywka

    Mike Slywka - 2005-09-16

    Logged In: YES

    I added an ob_clean() call to mime.php in the
    mime_print_body_lines function and that fixed it. Something
    was leaving a \n in the outputbuffer that was getting tacked
    onto the beginning of the mime 64 encoded attachments.

    Here's some context as to where I put the line:

    /* in case of base64 encoded attachments, do not buffer
    Instead, echo the decoded attachment directly to
    screen */
    if (strtolower($encoding) == 'base64') {
    if (!$ent_id) {
    $query = "FETCH $id BODY[]";
    } else {
    $query = "FETCH $id BODY[$ent_id]";
    /* MWS - Try to flush the output stream to get rid
    of a \n character that is screwing up the mime64 attachments */

    } else {
    $body = mime_fetch_body ($imap_stream, $id, $ent_id);
    echo decodeBody($body, $encoding);

    Hopefully that doesn't break anything else. It doesn't
    explain why there is a \n character there in the first
    place, but as long as my users can get their all important
    word doc attachments I'm happy.


  • Jonathan Angliss

    Logged In: YES

    This would still suggest that there might be a plugin, a
    file, a config, or something similar that is sending the
    additional \n. You could try extracting the 1.4.5 source
    code again from a fresh download from the sf.net website,
    without plugins, and see if you have any issues with that.

  • Thijs Kinkhorst

    Thijs Kinkhorst - 2005-11-22

    Logged In: YES

    Mike: I'd appreciate it if you could tell us whether a clean
    installation of SquirrelMail solves the problem. Do you
    think that's possible?

  • Tomas Kuliavas

    Tomas Kuliavas - 2006-06-05
    • assigned_to: nobody --> tokul
  • Thijs Kinkhorst

    Thijs Kinkhorst - 2006-07-06

    Logged In: YES

    Hello Mike,
    We've just released a new stable version 1.4.7 and a lot of
    bugs have been fixed. It would really help us if
    you could test if it's still present, please let us know.

  • Tomas Kuliavas

    Tomas Kuliavas - 2006-07-06

    Logged In: YES

    SquirrelMail 1.5.x functions/plugin.php has output buffering
    code that prevents output when plugins/*/setup.php files are
    loaded. Code is not present in 1.4.x.

  • Tomas Kuliavas

    Tomas Kuliavas - 2006-07-18

    Logged In: YES

    SquirrelMail 1.4.8 and 1.5.1 use output buffering when
    plugins are loaded and whitespace (new lines and spaces) is

  • Tomas Kuliavas

    Tomas Kuliavas - 2006-07-18
    • status: open --> closed-fixed

Log in to post a comment.

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

Sign up for the SourceForge newsletter:

No, thanks