Bug 5460 - whitelist_from_rcvd doesn't work on MTAs with PTR lookups disabled
Summary: whitelist_from_rcvd doesn't work on MTAs with PTR lookups disabled
Status: RESOLVED FIXED
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Score Generation (show other bugs)
Version: 3.2.0
Hardware: PC Linux
: P5 normal
Target Milestone: 3.2.3
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-10 15:43 UTC by Jason Haar
Modified: 2007-07-30 05:58 UTC (History)
0 users


Attachment Type Modified Status Actions Submitter/CLA Status
sample that shows the lack of PTR lookups message/rfc822 None Jason Haar [NoCLA]
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 Jason Haar 2007-05-10 15:43:47 UTC 
It looks to me like there was a fundamental change in how SA 3.2.0 operates WRT 
whitelist_from_rcvd compared with 3.1.*?

I had working whitelist_from_rcvd entries that broke when I went 3.2.0.

We use Qmail which defaults to not doing PTR lookups - which means it's Received
headers contains IPs instead of PTR records. Under 3.1.8 I *think* (don't have
the system anymore) SA did it's own PTR (RDNS) lookups whereas under 3.2.0 it
now assumes the MTA did it?

That seems a tad broken. I mean besides requiring a MTA to actually do this,
there will also be the case where the MTA's PTR lookup fails due to a time out,
and SA would be able to successfully do the same lookup 0.5sec later, etc.

Am I totally wrong about this, or has this occurred? If this is expected
behaviour, could the man page Mail::SpamAssassin::Conf be changed to reflect
this, as there is no mention in there. (e.g. "NOTE: for whitelist_from_rcvd to
work, you need to ensure your MTA is configured to do PTR lookups so that the
Received: headers reflect hostnames instead of raw IP addresses")

PS: I enabled PTR lookups on Qmail to get around this - but it was a bit of a
shocker when we suddenly started tagging as Spam all email from trademe.co.nz -
the "eBay" of New Zealand - who we had a whitelist for.

Thanks!
Comment 1 Daryl C. W. O'Shea 2007-05-10 15:52:09 UTC 
This may be a side effect of the code change to no longer using DNS (ever) to
automatically determine trust.

I have no idea if 3.1 would do a lookup for you in the described case.  Debug
output (along with the sample message used) from both 3.1 and 3.2 demonstrating
this would be welcomed.  Failing a debug comparison, at least a sample message
might provoke someone to look at it since I don't think any of the devs would
touch qmail with a 10' pole in order to generate their own sample.  At least I
won't.
Comment 2 Jason Haar 2007-05-10 15:59:31 UTC 
Created attachment 3942 [details]
sample that shows the lack of PTR lookups

just changing the string "unknown" in the Received: header to
mta1.wlg.trademe.co.nz suddenly allows whitelist_from_rcvd to work
Comment 3 Sidney Markowitz 2007-06-04 22:00:24 UTC 
Moving items off the 3.2.1 queue to 3.2.2 to facilitate a quick release.
If you can get this in Review status right away feel free to move it back
Comment 4 Justin Mason 2007-07-30 05:58:05 UTC 
(In reply to comment #1)
> This may be a side effect of the code change to no longer using DNS (ever) to
> automatically determine trust.

Yep, it is.  it already is documented:

'=item whitelist_from_rcvd addr@lists.sourceforge.net sourceforge.net
...
This string is matched against the reverse DNS lookup used during the handover
from the internet to your internal network's mail exchangers.'

this should be clearer, though.  checked into trunk:

: jm 114...; svn commit -m "clarify documentation to note clearly that MXes must
perform DNS name resolution, for whitelist_from_rcvd to work"
lib/Mail/SpamAssassin/Conf.pm
Sending        lib/Mail/SpamAssassin/Conf.pm
Transmitting file data .
Committed revision 560957.

and b320 as a trivial doc fix:

: jm 85...; svn commit -m "clarify documentation to note clearly that MXes must
perform DNS name resolution, for whitelist_from_rcvd to work"
lib/Mail/SpamAssassin/Conf.pm
Sending        lib/Mail/SpamAssassin/Conf.pm
Transmitting file data .
Committed revision 560956.


> I have no idea if 3.1 would do a lookup for you in the described case.  Debug
> output (along with the sample message used) from both 3.1 and 3.2 demonstrating
> this would be welcomed.  Failing a debug comparison, at least a sample message
> might provoke someone to look at it since I don't think any of the devs would
> touch qmail with a 10' pole in order to generate their own sample.  At least I
> won't.

hm. that reaction might be a little OTT ;)