SquirrelMail

Thanks for everyone's help. This is now fixed in our development and
stable streams.

Fix the "function timezone()" in Deliver.class.php:

< $zonename = '('.strftime('%Z').')';
< $result = sprintf ("%s%02d%02d %s", $sign, $diff_hour,
$diff_minute,
< $zonename);

> $result = sprintf ("%s%02d%02d", $sign, $diff_hour,
$diff_minute);

This results into dates like "Date: Sat, 23 Feb 2008 22:44:14 +0100" which
is perfect. The time zone is indicated by the "+0100". See also RFC822
5.1.

Refering the problem to PHP or windows is not enough: If you invoke a
method you must be able to handle the result properly - always.

Fix this please.

You're right, just encoding doesn't cut it.
I had a closer look at the RFC822 and RFC2822. Could it be teh the header
is non compliant as it is even with only "CET".
As i read it you have the option to give the time delta or one of zone
items listed in the RFC, but not both. Maybe just remove the zonename?

I think this is related to the output of the %Z string formatting under
Windows. For some reason Windows will return a full timezone representation
in some circumstances. We may be able to change this but that would require
some testing of course.

I cannot just endode Mitteleuropaeische Zeit because this would still
generate a header that is not RFC 822 compliant.

Well, "Mitteleuropäische Zeit" is a perfectly valid name for the
timezone. CET or MEZ are just abbreviations.
Of course is does get that timezone name from the OS. It is still in
SquirrelMails responsibility to make the SMTP header comply to the RFC
standard, meaning to properly encode the stuff you write in there no matter
where you get that information from.
Also this is trivial. Just "encodeHeader()" the zonename.

SquirrelMail does not set that string itself - it probably gets wrong
timezone information from somewhere (the operating system?). The zone you
indicated must be written as "CET" not "Mitteleuropäische Zeit".