http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5373
------- Additional Comments From [EMAIL PROTECTED] 2007-03-25 17:12 ------- Sorry, I'm pulling in this quote from http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5374 because I think it's more related to this and should respond here: > FWIW, I think extending trusted_networks towards the sender further than > internal_networks is pointless 99.99% of the time (your local DNS cache > absorbs > any penalty of a few extra DNS lookups in systems busy enough for the penalty > to > be an issue). I recommend that people don't do it. The only place I see > differing trusted/internal configs is on the MSA side where you can't > determine > auth from the headers (or POPAuth). With msa_networks now implemented it's > not > even necessary in this case anymore. In hindsight, I think I'm agreeing with this. I think I was confused about the use of -lastexternal, and now I'm not convinced that my patch here actually adds anything useful to DNSBL checks. So I went back and checked some more to see what it was helping on, and really it seemed to be 2 cases: 1. Forwarder hosts that for some reason were on an RBL. By extended trust into them, their IPs aren't checked, and thus when some persons forwarding service ends up being RBL listed for some reason, suddenly a lot of their email was being marked as spam 2. SPF checks for forwarding services that don't use SRS because I have some other code that overrides Mail::SpamAssassin::Plugin::SPF::_get_relay to check each relay for ->{trust_type}. Apart from that though, I'm not sure any of this is actually a help, and I may have been leading things up the garden path. Still, things that reduce false positives and overall accuracy for users is always a good thing. Rob ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.
