Bug 4334 - _check_whitelist_rcvd logic mismatch
Summary: _check_whitelist_rcvd logic mismatch
Status: RESOLVED DUPLICATE of bug 4425
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (Eval Tests) (show other bugs)
Version: 3.0.3
Hardware: Other other
: P3 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-16 13:38 UTC by Ken Barr
Modified: 2005-07-16 10:33 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 Ken Barr 2005-05-16 13:38:32 UTC 
This function in EvalTests.pm doesn't match the Conf manpage or my intuition.

I have a message with two received headers:

Received: from trusted.internal.host ...
Received: from untrusted.forged.host ...
From: someone@internal.host

I'd expect that 'whitelist_from_rcvd *@internal.host internal.host' would NOT
whitelist this because when the message is handed off to the internal network,
forged.host's IP doesn't rDNS to internal.host.  Yet the loop in 
_check_whitelist_rcvd returns '1' as long as ANY host is trusted.  It doesn't
fall through to the $found_forged=1 line.

I think you should search the list backwards (first trusted, then untrusted). 
If you hit a trusted host, continue the loop.  If you hit an untrusted one break
and check the relays list.  If you make it to the end without hitting an
untrusted host, then it's not forged.  

If this is not the correct interpretation of whitelist_from_rcvd, perhaps the
documenation could be clearer.
Comment 1 Bob Menschel 2005-07-06 22:50:05 UTC 
Ken, 

My understanding of whitelist_from_rcvd agrees with yours. And when I test
whitelist_from_rcvd under 3.1.0 (pre), with your scenario, the rule behaves
correctly (does not match). 

If you're still having this problem, please post sample message, your local.cf
and/or user_prefs which define the trusted networks and whitelist, and a -D
debug output so I can try to figure out where the problem is.  Thanks.
Comment 2 Bob Menschel 2005-07-16 18:33:59 UTC 
Looks like this is the same bug mentioned in bug 4425. Marking this earlier
report as the duplicate of 4425, since that one has attached sample email, logs,
and proposed patch. 

*** This bug has been marked as a duplicate of 4425 ***