Bug 6021 - dbg: received-header: relay 92.104.118.79 trusted? yes=incorrect
Summary: dbg: received-header: relay 92.104.118.79 trusted? yes=incorrect
Status: RESOLVED INVALID
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Plugins (show other bugs)
Version: 3.1.7
Hardware: Other All
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords: dns
Depends on:
Blocks:
 
Reported: 2008-11-21 03:02 UTC by Ron Groen
Modified: 2008-11-22 21:08 UTC (History)
0 users


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 Ron Groen 2008-11-21 03:02:49 UTC 
sample message
---------------------------------------------------------------------------
Received: from sdcd (unknown [92.104.118.79])
	by smtp.myservername.nl (Postfix) with ESMTP id 913F2150001B;
	 Thu, 20 Nov 2008 13:05:48 +0100 (CET)
Received: from sdcd by mx3.earthlink.net; Thu, 20 Nov 2008 13:05:48 +0100
Subject: test
not working
-------------
result RELAY_CH recognition from 

header    RELAY_CH X-Relay-Countries=~/\bCH\b/
describe  RELAY_CH Relayed through SWITZERLAND 
score     RELAY_CH 4

RELAY_CH is not found in Xlines

no X-Spam-status lines are reported in spamassassin  -D <spam3.txt  >spam3a.txt 2>spam3b.txt

detail debugging
[4653] dbg: dns: looking up PTR record for '92.104.118.79'
[4653] dbg: dns: PTR for '92.104.118.79': '79-118.104-92.cust.bluewin.ch'
[4653] dbg: received-header: parsed as [ ip=92.104.118.79 rdns=79-118.104-92.cust.bluewin.ch helo=sdcd by=smtp.aha4adsl.nl ident= envfrom= intl=0 id=913F2150001B auth= ]
[4653] dbg: dns: looking up A records for 'smtp.myservername.nl'
[4653] dbg: dns: A records for 'smtp.myservername.nl': 192.168.0.3
[4653] dbg: dns: looking up A records for 'smtp.myservername.nl'
[4653] dbg: dns: A records for 'smtp.myservername.nl': 192.168.0.3
[4653] dbg: received-header: 'by' smtp.myservername.nl has private IP 192.168.0.3
[4653] dbg: received-header: 'by' smtp.myservername.nl has no public IPs
[4653] dbg: received-header: relay 92.104.118.79 trusted? yes internal? no
last line trusted? yes is WRONG
------------------------------------------------------------------------------

working is :

Received: from sdcd (unknown [92.104.118.79])
	by smtp.myservername.nl (Postfix) with ESMTP id 913F2150001B;
	 Thu, 20 Nov 2008 13:05:48 +0100 (CET)
Received: from [92.104.118.79] by mx3.earthlink.net; Thu, 20 Nov 2008 13:05:48 +0100
Subject: test
working fine

X-Spam-Status: Yes, score=11.3 required=5.0 tests=MISSING_HB_SEP,
	MISSING_HEADERS,RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_XBL,RELAY_CH,
	TO_CC_NONE autolearn=disabled version=3.1.7-deb

[4653] dbg: received-header: parsed as [ ip=92.104.118.79 rdns=79-118.104-92.cust.bluewin.ch helo=sdcd by=smtp.sampleserver.nl ident= envfrom= intl=0 id=913F2150001B auth= ]
[4653] dbg: dns: looking up A records for 'smtp.sampleserver.nl'
[4653] dbg: dns: A records for 'smtp.sampleserver.nl': 
[4653] dbg: dns: looking up A records for 'smtp.sampleserver.nl'
[4653] dbg: dns: A records for 'smtp.sampleserver.nl': 
[4653] dbg: received-header: relay 92.104.118.79 trusted? no internal? no

last line trusted? yes is RIGHT
Comment 1 Matt Kettler 2008-11-21 03:25:58 UTC 
If you don't want SA to trust 92.104.118.79, or other machines dropping mail off at smtp.myservername.nl you need to manually configure trusted_networks.

See the article on this topic in the wiki:

http://wiki.apache.org/spamassassin/TrustPath
Comment 2 Matt Kettler 2008-11-22 21:08:13 UTC 
I'm going to mark this as invalid, as it's a well documented limitation of the auto-guessing code, and one that's not really fixable in any way that has come up over the past several years. 

You can reverse the default assumption about the first routeable IP, but that just breaks the trust mechanism for a different set of users. Those users end up with under-trust which causes just as many problems as over-trust.

About the only thing we could do here is offer a config option to flip the assumption. However that only makes fixing it easier, it doesn't change that the admin will need to recognize they have this problem to deal with.

Other bugs worth referencing:

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

If there's any real issues, please post them and reopen it.