#1881 Attachments decode base64 corrupt

closed-fixed
None
5
2006-07-18
2005-09-14
Mike Slywka
No

Hi,

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
work.

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?

Thanks,

Mike

Discussion

1 2 > >> (Page 1 of 2)
    • status: open --> pending
     
  • Logged In: YES
    user_id=476981

    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
    user_id=1344752

    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
    14. bookmarks
    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

     
  • Mike Slywka
    Mike Slywka
    2005-09-15

    Logged In: YES
    user_id=1344752

    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

     
  • Mike Slywka
    Mike Slywka
    2005-09-16

    Logged In: YES
    user_id=1344752

    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
    them.
    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 */
    ob_clean();

    sqimap_run_command($imap_stream,$query,true,$response,$message,$uid_support,'sqimap_base64_decode','php://stdout',true);
    } 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.

    mike

     
  • Logged In: YES
    user_id=620333

    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.

     
  • Logged In: YES
    user_id=285765

    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
     
  • Logged In: YES
    user_id=285765

    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.
    Thanks!

     
1 2 > >> (Page 1 of 2)