You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by David Lee <t....@durham.ac.uk> on 2006/03/22 16:46:44 UTC
INVALID_DATE
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: +447793xxxxxx@mmail.co.uk
> To: <t....@durham.ac.uk>
> Subject: {Spam?} MMail Message
> X-Mailer: <WIN Mail>
> Message-ID: <AR...@argus>
> 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.)
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: Durham University :
: http://www.dur.ac.uk/t.d.lee/ South Road :
: Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
Re: INVALID_DATE
Posted by Philip Prindeville <ph...@redfish-solutions.com>.
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: +447793xxxxxx@mmail.co.uk
>>To: <t....@durham.ac.uk>
>>Subject: {Spam?} MMail Message
>>X-Mailer: <WIN Mail>
>>Message-ID: <AR...@argus>
>>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
Re: INVALID_DATE
Posted by Loren Wilton <lw...@earthlink.net>.
> > From: +447793xxxxxx@mmail.co.uk
> > 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)
> 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
I personally consider their date to be completely bogus and worth the 2
points or so.
However, I think you should reconsider blithly dismissing the other two,
which are worth nearly 4 points between them. Assuming this joint keeps its
hostname reasonably constant, or there are other identifying characteristics
such that this can be determined to be a mobile phone mail provider, I see
no reason those other two hits should not go away. It would be moderately
easy to meta their tests with some other stuff to decide that in this case a
from ending in numbers is perfectly ok.
I would suggest opening an enhancement request in BZ showing the appropriate
part of the message, and requesting that they fix it up so that the
inappropriate hit doesn't happen.
Loren
Re: INVALID_DATE
Posted by Craig Morrison <cr...@2cah.com>.
David Lee wrote:
>
>> Date: Wed, 22 Mar 06 12:00:00 GMT Standard Time
[snip.]
> 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:
>
You may wish to remind them that section 4.3 also references obsolete
date-time stamps.
> Can someone demonstrate from RFC2822 that "GMT Standard Time" definitely
> is, or definitely isn't, technically legal?
Section 3.3 clearly states what date-time stamps should be. Specifically
time zone information is to be present in this format:
zone = (( "+" / "-" ) 4DIGIT) / obs-zone
The relevant part of RFC2822 section 3.3:
minutes). The form "+0000" SHOULD be used to indicate a time zone at
Universal Time. Though "-0000" also indicates Universal Time, it is
used to indicate that the time was generated on a system that may be
in a local time zone other than Universal Time and therefore
indicates that the date-time contains no information about the local
time zone.
Granted, they are falling back on the obs-zone format. Which is just
that, obsolete.
If they do want better compliance with the obs-zone why don't they just
drop the "Standard Time"?
Craig