[exim] sender_rcvhost versus SpamAssassin RDNS_NONE

Top Page
Delete this message
Reply to this message
Author: Christian Balzer
Date:  
To: exim-users
Subject: [exim] sender_rcvhost versus SpamAssassin RDNS_NONE

Hello,

If you use the default Exim received_header_text definition in combination
with SpamAssassin you will be bitten by one of the (many) potential false
positives of SA. It seems that the SA folks assume Received headers to be
constructed like in this example:
http://wiki.apache.org/spamassassin/EnvelopeSenderInReceived
linked from this thread:
http://old.nabble.com/-Bug-5926--New:-false-positive-on-RDNS_NONE-td18020799.html

This means that headers like this do get hit with RDNS_NONE (and at up
to 2.4 points in recent SA versions!):
---
Received: from tahini.csx.cam.ac.uk ([131.111.8.192])
---

While potentially fishy ones like these pass with flying colors:
---
Received: from nm07omta07.auone-net.jp ([210.141.108.72] helo=nmomta.auone-net.jp)
Received: from 54.1.32.202.bf.2iij.net ([202.32.1.54] helo=mx3.keishin.co.jp)
Received: from mkrm1120d.rakuten.co.jp ([203.190.62.120] helo=mkrm.rakuten.co.jp)
---

The only 100% correct results are for ones like this:
---
Received: from [202.29.21.52] (helo=AOB)
---

In summary the IP address in brackets with any other text separated by a
space within the parenthesis seems to make the RDNS_NONE check happy.

Now while this should be addressed by the SA folks, can somebody here
conjure up a received_header_text definition that would play nice with
SA's quirky RDNS_NONE rule?

Regards,

Christian
-- 
Christian Balzer        Network/Systems Engineer                
chibi@???       Global OnLine Japan/Fusion Communications
http://www.gol.com/