On Mon, Jan 29, 2007 at 08:54:01PM +0100, Sander wrote:
> Date: Mon, 29 Jan 07 20:33:10 +0100
>
> So, wondering what the problem would be, i read the RFC. This says that
> a 2-digit year is obsolete, but supported for backwards compatibility.
FWIW, SA doesn't care about RFC compliance in as much
Dear list,
I have an e-mail using a two-digit year in the Date: header. It seems
that INVALID_DATE is triggered.
The complete (but obfuscated) e-mail is here:
>From [EMAIL PROTECTED] Mon Jan 29 20:33:33 2007
Return-path: <[EMAIL PROTECTED]>
Envelope-to: [EMAIL PROTECTED]
Delivery-date
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Lee wrote:
> On Fri, 24 Mar 2006, mouss wrote:
>
>> Daryl C. W. O'Shea a écrit :
>>> David Lee wrote:
>>>
>>>> If, conversely, it is not in breach, then SA has a problem: it shouldn't
>>
On Fri, 24 Mar 2006, mouss wrote:
> Daryl C. W. O'Shea a écrit :
> > David Lee wrote:
> >
> >> If, conversely, it is not in breach, then SA has a problem: it shouldn't
> >> be marking it "INVALID_DATE". Incidentally, it is this aspect (rather
From: "mouss" <[EMAIL PROTECTED]>
I lately saw an FP with RCVD illegal IP, because of a 127.0.0.80 IP.
while this rarely used, it's not illegal. so the rule is just bogus IMHO.
50_scores.cf:score RCVD_ILLEGAL_IP 1.585 0.234 1.813 0.288
With a set 3 score of 0.288, I'd say this isn't a big hi
From: <[EMAIL PROTECTED]>
c:\>man strftime
'man' is not recognized as an internal or external command,
operable program or batch file.
The mere fact that documentation is less accessible on windows should not be
taken as an excuse by programmers to reinvent the wheel as an egg-shaped thingy
Daryl C. W. O'Shea a écrit :
>
> I'm not being a "std crusader". I'm simply pointing out that someone
> going there own way shouldn't expect everyone to accept their way,
> especially when there's an established majority going the other way.
>
> Just because a mail is "standards compliant" doesn
mouss wrote:
I here mean that you can't go as a "std crusader" and at the same time
break the standards by tagging std compliant mail. statistics are no
excuse for rejecting/tagging mail.
I'm not being a "std crusader". I'm simply pointing out that someone
going there own way shouldn't expec
Nigel Frankcom a écrit :
> Just a mild - un-warlike comment, but - there are a few of us out here
> that use win-based servers; I freely admit win have a skewed idea of
> dates, but that doesn't change the problem.
>
> Craig kindly wrote an awk that did the date conversion for my (squid)
> logs so
Daryl C. W. O'Shea a écrit :
> David Lee wrote:
>
>> If, conversely, it is not in breach, then SA has a problem: it shouldn't
>> be marking it "INVALID_DATE". Incidentally, it is this aspect (rather
>> than any other) of the date that is triggerin
Just a mild - un-warlike comment, but - there are a few of us out here
that use win-based servers; I freely admit win have a skewed idea of
dates, but that doesn't change the problem.
Craig kindly wrote an awk that did the date conversion for my (squid)
logs so that I can get some sanity from my l
Craig Morrison a écrit :
> I guess 'man strftime' is too difficult to manage. ;-D
>
sure, but unix and C are obsolete.
(sure, this calls for war, but I didn't start it).
David Lee wrote:
If, conversely, it is not in breach, then SA has a problem: it shouldn't
be marking it "INVALID_DATE". Incidentally, it is this aspect (rather
than any other) of the date that is triggering this SA rule, isn't it?
I guess we could fix it
David Lee wrote:
On Thu, 23 Mar 2006, Craig Morrison wrote:
At any rate and to try and bring this discussion somewhat back on topic,
strftime makes it trivial to change date formats merely by changing the
format string given as one of its arguments. Any debate regarding
difficulty of change by t
t timezone
> specification is in breach of RFC 822 or 2822 ?
>
> If it is in breach, and can be shown to be, then this can be
> presented, factually (not as opinion), complete with derivation, to
> the ISP.
>
> If, conversely, it is not in breach, then SA has a problem: it
>
h, and can be shown to be, then this can be presented,
factually (not as opinion), complete with derivation, to the ISP.
If, conversely, it is not in breach, then SA has a problem: it shouldn't
be marking it "INVALID_DATE". Incidentally, it is this aspect (rather
than any other
On Thursday 23 March 2006 08:52, [EMAIL PROTECTED] wrote:
>> c:\>man strftime
>> 'man' is not recognized as an internal or external command,
>> operable program or batch file.
>
>The mere fact that documentation is less accessible on windows should
> not be taken as an excuse by programmers to rein
[EMAIL PROTECTED] wrote:
c:\>man strftime
'man' is not recognized as an internal or external command,
operable program or batch file.
The mere fact that documentation is less accessible on windows should not be
taken as an excuse by programmers to reinvent the wheel as an egg-shaped thingy
Wol
> c:\>man strftime
> 'man' is not recognized as an internal or external command,
> operable program or batch file.
The mere fact that documentation is less accessible on windows should not be
taken as an excuse by programmers to reinvent the wheel as an egg-shaped thingy
Wolfgang Hamann
Strftime does not exist either. Windows is DUMB. It IS found in VC++'s
documentation, though.
{^_-}
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Wednesday, March 22, 2006 23:26
Subject: RE: INVALID_DATE
jdow wrote:
c:\>man strftime
'man' is not r
> > From: [EMAIL PROTECTED]
> > 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 &q
jdow wrote:
> c:\>man strftime
> 'man' is not recognized as an internal or external command,
> operable program or batch file.
Heh. Actually, on my machine:
C:\>man strftime
This command is not supported by the help utility. Try "strftime /?".
... of course, I should probably note
C:\custom-p
Ah, but "man strftime" does not universally apply. For people with their
heads buried deeply enough up the Windows mire they've probably never heard
of either the RFCs, man, or strftime. That's sad. It's life in the world
with Microsoft in it.
{^_-}
- Original Message -
From: "Philip Pri
It's part of the ISO C standard runtime libraries.
-Philip
jdow wrote:
>Oh, let's mix up this top/bottom miscegenation with a topper this time
>(We're human. It behooves us to prove it and adapt to the other guy's
>peculiarities or necessities.)
>
>Rant out of the way here is a simple obser
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&q
?
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 Ma
o: users@spamassassin.apache.org
> Subject: RE: INVALID_DATE
>
> 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
al
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:
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"
t;[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 -
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_NAM
31 matches
Mail list logo
