SquirrelMail

Logged In: YES
user_id=225877

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

Logged In: YES
user_id=225877

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.

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!

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?

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

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

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?