Potentially problematic feedback between greylisting and spam filtering
June 3, 2009,
Greylisting may affect the spam score of the message when it eventually is accepted by the mail server, which may have unexpected consequences.
Over here at Loco we employ several lines of defense when it comes to fighting spam. The first line is formed by greylisting, which obviously may cause some delay in the delivery of some messages. Today we noticed a very interesting interaction between greylisting and our second line of defense against spam, filtering with SpamAssassin. More or less by coincidence we stumbled across a very interesting feedback between these two systems. To illustrate with some (anonymized) headers of the email we observed the feedback in:
... X-Spam-Status: No, score=3.179 tagged_above=-1000 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, FH_FROMEML_NOTLD=2.696, FROM_NO_USER=1.483, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457] Received: from mailserver.example.com ([127.0.0.1]) by localhost (mailserver.example.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvwZcEGtlPwN for <firstname.lastname@example.org>; Wed, 3 Jun 2009 13:51:29 +0200 (CEST) X-Greylist: delayed 13785 seconds by postgrey-x.xx at mailserver.example.com; Wed, 03 Jun 2009 ...
What you see here from bottom to top are a header inserted by postgrey stating that a message has been delayed by almost 4 hours before being accepted, the 'received' header inserted by amavisd-new which also applies SpamAssassin, and the scores that SpamAssassin assigned to the mail. The most interesting of these is the test labeled DATE_IN_PAST_03_06, that is applied when the message has a Date header between 3 and 6 hours older than the moment the message is accepted. This is intended to trap messages from poorly configured systems, but in this particular case the difference is due to postgrey rejecting the initial delivery attempt and the delay before the sending server retries delivering the message. The increment to the overall spam score is minimal for this test, but the spam contribution for this test can be configured to a different value, which might lead to some messages being scored as spam as a conseqence.
What it boils down to, is that using postgrey as a spam fighting measure may affect the score in a spam filter, creating a form of positive feedback within the entire system. It would be interesting to hear about any other situations where seemingly independent spam protection measures actually have some form of interaction.