Bug 5996 - DATE_IN_FUTURE_96_XX false positives
Summary: DATE_IN_FUTURE_96_XX false positives
Status: RESOLVED WORKSFORME
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: 3.2.3
Hardware: PC Linux
: P3 major
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-12 08:31 UTC by Alex Craven
Modified: 2017-12-29 05:48 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Craven 2008-10-12 08:31:40 UTC 
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 <alex@example.com>; Sun, 12 Oct 2008 23:07:23 +0800
Received: from krei by winston with local (Exim 4.69)
        (envelope-from <krei@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 <alex@example.com>
To: alex@example.com
Subject: testing
Message-ID: <20081012150716.GB21588@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=<krei@example.com>, size=519, class=0, nrcpts=1, msgid=<20081012150716.GB21588@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 <20081012150716.GB21588@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=<20081012150716.GB21588@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
Comment 1 Azamat Hackimov 2009-02-03 01:53:40 UTC 
Either your server or relay has have incorrect timezone.
Maybe your time is LOCAL.
Comment 2 Alex Craven 2009-02-03 05:02:48 UTC 
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.
Comment 3 Alex Craven 2009-02-03 05:06:26 UTC 
...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.
Comment 4 Sidney Markowitz 2009-02-03 15:08:11 UTC 
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?
Comment 5 Giovanni Bechis 2017-12-28 22:58:37 UTC 
No answer in many years, ttl timeout ?
Comment 6 Bill Cole 2017-12-29 05:48:43 UTC 
(In reply to Giovanni Bechis from comment #5)
> No answer in many years, ttl timeout ?

Yes. Reporter didn't answer critical questions, can't reproduce.