You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2008/10/12 17:31:41 UTC

[Bug 5996] New: DATE_IN_FUTURE_96_XX false positives

https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5996

           Summary: DATE_IN_FUTURE_96_XX false positives
           Product: Spamassassin
           Version: 3.2.3
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P3
         Component: Rules
        AssignedTo: dev@spamassassin.apache.org
        ReportedBy: krei@it.net.au


I'm seeing common but intermittent false positives from the
DATE_IN_FUTURE_96_XX test, using spamassassin as a milter. Sample headers (and
corresponding sendmail logs) follow (I've masked my email address, everything
else is verbatim). Note that all dates are within about 10 seconds of each
other; I'm in UTC+2, relaying via a server in UTC+8. Any idea what may be
causing this?

Sample headers generating false positive:

Return-Path: krei@example.com
Received: from winston (m068b.studby.ntnu.no [129.241.129.68])
        (authenticated bits=0)
        by persepolis.ntrust.net.au (8.13.8/8.13.8/Debian-3) with ESMTP id
m9CF7HLX031308
        (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT)
        for <al...@example.com>; Sun, 12 Oct 2008 23:07:23 +0800
Received: from krei by winston with local (Exim 4.69)
        (envelope-from <kr...@winston.example.com>)
        id 1Kp2XM-000104-TF
        for alex@example.com; Sun, 12 Oct 2008 17:07:16 +0200
Date: Sun, 12 Oct 2008 17:07:16 +0200
From: Alex Craven <al...@example.com>
To: alex@example.com
Subject: testing
Message-ID: <20...@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by
milter-greylist-3.0 (persepolis.ntrust.net.au [203.82.209.73]); Sun, 12 Oct
2008 23:07:23 +0800 (WST)
X-Spam-Status: No, score=-101.2 required=5.0 tests=AWL,BAYES_00,
        DATE_IN_FUTURE_96_XX,USER_IN_WHITELIST autolearn=no version=3.2.3
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on
        persepolis.ntrust.net.au


sendmail log segment:

Oct 12 23:07:23 persepolis milter-greylist: User mailrelay authenticated,
bypassing greylisting
Oct 12 23:07:23 persepolis sm-mta[31308]: m9CF7HLX031308:
from=<kr...@example.com>, size=519, class=0, nrcpts=1,
msgid=<20...@example.com>, proto=ESMTP, daemon=MTA-v4,
relay=m068b.studby.ntnu.no [1
29.241.129.68]
Oct 12 23:07:23 persepolis sm-mta[31308]: m9CF7HLX031308: Milter add: header:
X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by
milter-greylist-3.0 (persepolis.ntrust.net.au [203.82.209.73]);
 Sun, 12 Oct 2008 23:07:23 +0800 (WST)
Oct 12 23:07:23 persepolis spamd[23824]: spamd: connection from localhost
[127.0.0.1] at port 50771
Oct 12 23:07:23 persepolis spamd[23824]: spamd: setuid to krei succeeded
Oct 12 23:07:23 persepolis spamd[23824]: spamd: processing message
<20...@example.com> for krei:10407
Oct 12 23:07:25 persepolis spamd[23824]: spamd: clean message (-101.2/5.0) for
krei:10407 in 1.4 seconds, 988 bytes. 
Oct 12 23:07:25 persepolis spamd[23824]: spamd: result: . -101 -
AWL,BAYES_00,DATE_IN_FUTURE_96_XX,USER_IN_WHITELIST
scantime=1.4,size=988,user=krei,uid=10407,required_score=5.0,rhost=localhost,raddr=127.0.0.1,r
port=50771,mid=<20...@example.com>,bayes=0.000000,autolearn=no
Oct 12 23:07:25 persepolis sm-mta[31308]: m9CF7HLX031308: Milter add: header:
X-Spam-Status: No, score=-101.2 required=5.0
tests=AWL,BAYES_00,\n\tDATE_IN_FUTURE_96_XX,USER_IN_WHITELIST autolearn=no
version=3.2.3
Oct 12 23:07:25 persepolis sm-mta[31308]: m9CF7HLX031308: Milter add: header:
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08)
on\n\tpersepolis.ntrust.net.au
Oct 12 23:07:25 persepolis sm-mta[31308]: m9CF7HLX031308: Milter add: header:
X-Virus-Scanned: ClamAV 0.94/8414/Sun Oct 12 11:30:50 2008 on
persepolis.ntrust.net.au
Oct 12 23:07:25 persepolis sm-mta[31308]: m9CF7HLX031308: Milter add: header:
X-Virus-Status: Clean
Oct 12 23:07:25 persepolis spamd[32304]: prefork: child states: II


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 5996] DATE_IN_FUTURE_96_XX false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5996





--- Comment #3 from Alex Craven <kr...@it.net.au>  2009-02-03 05:06:26 PST ---
...furthermore, even if a timezone were mismatched I'd expect it to trigger a
rule in the vicinity of 12-24 hrs into future, not 96 hours.


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 5996] DATE_IN_FUTURE_96_XX false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5996





--- Comment #4 from Sidney Markowitz <si...@sidney.com>  2009-02-03 15:08:11 PST ---
The code for the date in future rules looks at the Resent-Date or Date header
and the various times in the Received header, looking for the smallest
difference other than a final Received header with an identical time. As I
recall, a bad date with no time zone is parsed as UTC+0 for the purpose of this
rule. It should have nothing to do with time zone setting on the SpamAssassin
server, other than if it is also a mail server that affects the time stamps in
Received headers.

This is very strange. If SpamAssassin is not seeing any Received headers, that
would trigger a different rule, not DATE_IN_FUTURE_96_XX. This could only
happen if SpamAssassin incorrectly parsed the date in one or more of the
Received headers or Date header or if one or more of those headers were mangled
before the message was delivered to SpamAssassin.

The rule trigger is independent of the current date, being based just on the
headers. When you say this is intermittent, do you mean that when you send the
same message back through SpamAssassin through the same milter the rule doesn't
trigger? Or does it consistently happen with the same message? If the latter,
could you run it through with the debug switch on and attach the debugging
output here?


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 5996] DATE_IN_FUTURE_96_XX false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5996





--- Comment #1 from Azamat Hackimov <az...@gmail.com>  2009-02-03 01:53:40 PST ---
Either your server or relay has have incorrect timezone.
Maybe your time is LOCAL.


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Bug 5996] DATE_IN_FUTURE_96_XX false positives

Posted by bu...@bugzilla.spamassassin.org.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5996





--- Comment #2 from Alex Craven <kr...@it.net.au>  2009-02-03 05:02:48 PST ---
I think not. This is the obvious explanation, and hence the first thing I
checked. You will note from the headers (and logs) supplied that all timezones
are correct and times are consistent.


-- 
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.