[RndTbl] SpamAssassin false positives on DATE_IN_FUTURE_96_Q?

Gilbert E. Detillieux gedetil at cs.umanitoba.ca
Fri Nov 18 15:41:17 CST 2011

On 2011-11-18 10:29, Peter O'Gorman wrote:
> Google turned up this:
> http://lists.nongnu.org/archive/html/spamass-milt-list/2010-05/msg00001.html
> Looks like the problem is spamass-milter's synthesized Received header,
> rather than the spamassassin rule.

Well spotted, Peter.  I guess I hadn't come up on the right sequence of 
keywords to bring that Google search result into the first page.

Yes, that does seem like the bug I've encountered.  I noticed that a lot 
of my false-positives (though not all) were on messages directly sent by 
authenticated SMTP clients, i.e. where there was no pre-existing 
Received header.  (I didn't realize that spamass-milter was faking one.)

My fix for authenticated clients was much simpler and cleaner than what 
was proposed on that page, however:  spamass-milter has a "-I" option 
that will skip calling spamc/spamd altogether for authenticated SMTP 

However, the false-positives still remain for non-authenticated clients. 
  At least I have a better idea of where the problem lies, and what to 
look for in terms of a solution.


> On 11/15/2011 10:45 AM, Gilbert E. Detillieux wrote:
>> On 2011-11-14 17:46, Kevin McGregor wrote:
>>> So you've changed the date manually to be exactly the same, and the rule
>>> doesn't trigger?
>> Well... Here's the weird thing: if I pass the exact same message through
>> spamc manually, I don't get the false positive on that rule. So, I tried
>> mailing that message back to myself from a non-local mailer (so that it
>> goes through spamass-milter again), but this generates extra "Received"
>> headers that change the behaviour. (I now get a trigger on the
>> DATE_IN_PAST_24_48 rule, since the message is now that old.)
>> So, I can't test under exactly the same conditions. Given that running
>> the message through spamc manually didn't trigger the rule, I'm tempted
>> to think it might be something in the spamass-milter configuration,
>> which is causing some information to not be transferred to spamc, or to
>> be transferred incorrectly. Not sure at this point.
>> Gilbert
>>> On Mon, Nov 14, 2011 at 4:56 PM, Gilbert E. Detillieux
>>> <gedetil at cs.umanitoba.ca <mailto:gedetil at cs.umanitoba.ca>> wrote:
>>> I mentioned this problem at the last round-table session, but didn't
>>> get a solution, so I thought I'd post it here, just in case anyone
>>> has any suggestions to offer.
>>> I'm still seeing a whole bunch of false positives in SpamAssassin,
>>> since an update was installed in mid-September on a CentOS 5.7
>>> system, for a rule called DATE_IN_FUTURE_96_Q, which is only
>>> supposed to be triggered when the "Date:" header has a date that is
>>> 4 days to 4 month ahead of the date in the "Received" header that
>>> has the _smallest_ difference in date.
>>> Here are the headers from the latest e-mail I've received with this
>>> false-positive. (I've stripped out irrelevant headers, for the sake
>>> of clarity and simplicity.)
>>> >From topfivestories at messagent.__itworldcanada.com
>>> <mailto:topfivestories at messagent.itworldcanada.com> Mon Nov 14
>>> 07:50:13 2011
>>> Received: from mail.messagent.itworldcanada.__com
>>> <http://mail.messagent.itworldcanada.com>
>>> (mail.messagent.itworldcanada.__com
>>> <http://mail.messagent.itworldcanada.com> [])
>>> by palladium.cs.umanitoba.ca
>>> <http://palladium.cs.umanitoba.ca> (8.13.8/8.13.8) with SMTP id
>>> pAEDoAxV028594
>>> for <gedetil at cs.umanitoba.ca
>>> <mailto:gedetil at cs.umanitoba.ca>>; Mon, 14 Nov 2011 07:50:12 -0600
>>> Date: Mon, 14 Nov 2011 08:50:13 -0500
>>> X-Spam-Status: No, score=-0.3 required=5.0
>>> tests=BAYES_00,DATE_IN_FUTURE___96_Q,
>>> HTML_MESSAGE,RP_MATCHES_RCVD autolearn=no version=3.3.1
>>> X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
>>> palladium.cs.umanitoba.ca <http://palladium.cs.umanitoba.ca>
>>> Note that I'm calling spamd via the spamass-milter on a system
>>> running sendmail. Note also, that in the above example, the only
>>> "Received" header was the one generated by my own server. (I've had
>>> other false positives, however, with multiple "Received" headers,
>>> all of which were within seconds of the time in the "Date" header.)
>>> Any ideas?

Gilbert E. Detillieux		E-mail:	<gedetil at cs.umanitoba.ca>
Dept. of Computer Science	Web:	http://www.cs.umanitoba.ca/~gedetil/
University of Manitoba		Phone:	(204)474-8161
Winnipeg MB CANADA  R3T 2N2	Fax:	(204)474-7609

More information about the Roundtable mailing list