Bug 1546

Summary:	When report_safe=1, timezone in Received: header in Win32 is syntactically invalid
Product:	Spamassassin	Reporter:	Dan Wing <dwing>
Component:	SAProxy	Assignee:	Daniel Quinlan <quinlan>
Status:	RESOLVED FIXED
Severity:	normal	CC:	thorsten.walenzyk
Priority:	P3	Keywords:	backport
Version:	2.50
Target Milestone:	2.50
Hardware:	PC
OS:	Windows 2000
Whiteboard:
Attachments:	proposed fix

Description Dan Wing 2003-02-24 12:46:17 UTC

On Windows, strftime() returns "Pacific Standard Time" instead of an abbreviated
timezone:

  Received: from localhost [127.0.0.1] by DWING-W2K4
    with SpamAssassin (2.50-dwing_pop3proxy_feb_24_1205 1.173-2003-02-20-exp);
    Mon, 24 Feb 2003 12:12:56 Pacific Standard Time

(Under FreeBSD, SA 2.5 correctly places "-0800" into the timezone in that header.)

This timezone isn't valid per RFC2822, which has this ABNF for the Received:
header's timezone.

  zone            =       (( "+" / "-" ) 4DIGIT) / obs-zone

This defect causes misordering of messages if an MUA uses the Received: header
to sort messages by date/time received.  Bug is currently experienced with the
MUA Outlook 2000.

This bug is in SA 2.50, not with the 2.4x that is currently distributed with
saproxy.exe

Comment 1 Michael Bell 2003-02-24 15:39:08 UTC

Confirmed. The following snippet demonstrates the issue (I just cut the string 
from permsgstatus.pm)

use POSIX qw(strftime);
my $newmsg = 	"\t". strftime ("%a, %d %b %Y %H:%M:%S %z", localtime)."\n";
print $newmsg;

Output is:
 Mon, 24 Feb 2003 15:33:27 Pacific Standard Time

Comment 2 Michael Bell 2003-02-24 18:18:36 UTC

Workaround: 

If the TZ Environmental variable is defined as follows in Win32 environment 
before SA is run, stuff will work: (next bit snagged from MSDN). Note that the 
comments about the Date/Time control panel do not appear to be of any use with 
the Timezone name.

Use the following syntax to set the TZ environment variable:

set TZ=tzn[+ | –]hh[:mm[:ss] ][dzn] 

tzn 
Three-letter time-zone name, such as PST. You must specify the correct offset 
from local time to UTC. 
hh 
Difference in hours between UTC and local time. Optionally signed. 
mm 
Minutes. Separated from hh by a colon (:). 
ss 
Seconds. Separated from mm by a colon (:). 
dzn 
Three-letter daylight-saving-time zone such as PDT. If daylight saving time is 
never in effect in the locality, set TZ without a value for dzn. The C run-time 
library assumes the United States' rules for implementing the calculation of 
Daylight Saving Time (DST). 
For example, to set the TZ environment variable to correspond to the current 
time zone in Germany, you can use one of the following statements:

set TZ=GST-1GDT
set TZ=GST+1GDT
These strings use GST to indicate German standard time, assume that Germany is 
one hour ahead of UTC, and assume that daylight savings time is in effect.

If the TZ value is not set, _tzset attempts to use the time zone information 
specified by the operating system. Under Windows 98/Me and Windows NT/2000/XP, 
this information is specified in the Control Panel's Date/Time application. If 
_tzset cannot obtain this information, it uses PST8PDT by default, which 
signifies the Pacific Time zone.

Comment 3 Daniel Quinlan 2003-02-24 18:36:53 UTC

Setting target milestone to 2.50.  I was able to reproduce the bug on
Windows XP Home with ActivePerl 5.6.

I will attach a patch to fix in a moment.  strftime %z is not portable
even on Unix.  The workaround should be unnecessary if this fix is applied.
I tested the fix on Windows XP Home with ActivePerl 5.6.

Comment 4 Daniel Quinlan 2003-02-24 18:38:57 UTC

Created attachment 675 [details]
proposed fix

Comment 5 Daniel Quinlan 2003-02-24 21:10:45 UTC

Adding backport keyword.  Not sure why this is a "backport" since I wrote it
for the stable tree.

Comment 6 Theo Van Dinter 2003-02-25 00:22:15 UTC

Subject: Re: [SAdev]  When report_safe=1, timezone in Received: header in Win32 is syntactically invalid

On Mon, Feb 24, 2003 at 06:38:58PM -0800, bugzilla-daemon@hughes-family.org wrote:
> Created an attachment (id=675)
> proposed fix

OKAY: looks good to me, especially since we already had a sub to do it. :)

Comment 7 Daniel Quinlan 2003-02-25 13:03:14 UTC

Note: fix committed to HEAD

Comment 8 Malte S. Stretz 2003-03-02 13:28:35 UTC

assign to me for backporting

Comment 9 Daniel Quinlan 2003-03-14 10:50:10 UTC

applying to branch

Comment 10 Daniel Quinlan 2003-03-14 10:50:44 UTC

OKAY fix applied to head and 2.50 branch, closing

Comment 11 Daniel Quinlan 2003-05-07 15:13:37 UTC

*** Bug 1867 has been marked as a duplicate of this bug. ***

Comment 12 Malte S. Stretz 2003-10-25 03:09:45 UTC

*** Bug 2587 has been marked as a duplicate of this bug. ***