Randal, Phil wrote:
For what it's worth, Vodafone's as bad (stuff changed to protect the
innocent):
From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Date: Nov 9, 2005 4:53 PM
Subject: You have received a new message
RFC2822 is unequivocal about the day month year order, the hour being 2
digits, and what the heck is this PM time zone?
This isn't a slight error or misinterpretation of RFC2822, it's an "f***
you" to it.
Doesn't anybody check these things before deploying automated services?
Cheers,
Phil
----
Phil Randal
Network Engineer
Herefordshire Council
Hereford, UK
-----Original Message-----
From: Philip Prindeville [mailto:[EMAIL PROTECTED]
Sent: 22 March 2006 16:10
To: users@spamassassin.apache.org
Subject: Re: INVALID_DATE
David Lee wrote:
System: SA 3.1.0 (called from MailScanner, called from sendmail.
The ISP "mmail.co.uk" (part of the O2 mobile phone ("cellphone" under
trans-Atlantic translation!) company here in the UK)
generates a peculiar
"Date:" format. So when it arrives here, our SA is tagging
it as spam.
Part of the headers:
Date: Wed, 22 Mar 06 12:00:00 GMT Standard Time
From: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
Subject: {Spam?} MMail Message
X-Mailer: <WIN Mail>
Message-ID: <[EMAIL PROTECTED]>
X-OriginalArrivalTime: 22 Mar 2006 12:00:00.0046 (UTC)
FILETIME=[253124E0:01C64DA8]
X-DurhamAcUk-MailScanner: Found to be clean
X-DurhamAcUk-MailScanner-SpamCheck: spam, SpamAssassin (score=6.804,
required 6, BAYES_40 -0.18, FROM_ENDS_IN_NUMS 2.53,
FROM_LOCAL_HEX 1.30, INVALID_DATE 2.19, NO_REAL_NAME 0.96)
X-DurhamAcUk-MailScanner-SpamScore: ssssss
For data privacy reasons, I have "x"d out some of the purely-digit
"From:" LHS.
Aside: the "FROM_ENDS_IN_NUMS" and "FROM_LOCAL_HEX" are probably
immutable, as the "mmail.co.uk" service definition uses a
mobile number
as that "From:" LHS.
The main addressable issue here seems to be the "INVALID_DATE". The
"Date:" supplied by Mmail does not have a simple timezone
(e.g. expect
"GMT"), but rather "GMT Standard Time". (Correct?)
This seems to me to be a clear breach of RFC2822. Mmail's
defence is that
section 4.3 ends:
Other multi-character (usually between 3 and 5) alphabetic
time zones
have been used in Internet messages. Any such time zone whose
meaning is not known SHOULD be considered equivalent to "-0000"
unless there is out-of-band information confirming their meaning.
and that the "usually 3 or 5 alphabetic" could (they argue)
include the
17-character "GMT Standard Time".
Can someone demonstrate from RFC2822 that "GMT Standard
Time" definitely
is, or definitely isn't, technically legal?
(If it does happen to be legal, and if this nevertheless
triggers SA's
INVALID_DATE, then we have an SA bug.)
Would "GMT (Standard Time)" be legal? (I raise that just in
case "mmail"
really need to keep that information in that place for some
reason; this
would give them a way out.)
In all engineering, including Software, the KISS principle applies.
Even if "GMT Standard Time" were legal (and it's doubtful),
what do you
get by using that string instead of "GMT" tout court?
In the old days of the Internet, when they first started having "bake
offs" as they
were called back then, if a standard was ambiguous, then you'd look at
whichever
vendors managed to interoperate... ask them how they had done
things... and
bless their way of interpreting the standard as the "right way".
(That's how we
ended up settling some thorny questions about IP security
option processing,
for instance...)
What you have here is a failure to interoperate. ;-)
-Philip
I guess 'man strftime' is too difficult to manage. ;-D
--
--
Craig
