Henrik K wrote: > On Tue, Aug 11, 2009 at 04:31:32AM +0100, RW wrote: >> On Sun, 09 Aug 2009 11:33:29 +0100 >> Cedric Knight <[email protected]> wrote: >> >> >>> header FH_HELO_EQ_D_D_D_D X-Spam-Relays-Untrusted =~ /^[^\]]+ >>> ... >>> header HELO_MISC_IP X-Spam-Relays-Untrusted =~ /^[^\]]+ >>> >> Possibly this is down to their running on the wrong boundary, these >> should be on the internal network boundary. > > All these are fixed to -External in SVN/3.3.
Quite a complicated issue. I'd posted before http://www.nabble.com/Understanding-Trusted-and-Internal-to22282224.html#a22292088 wondering why such rules didn't check X-Spam-Relays-External. However, when I test external equivalents like EXT_HELO_DYNAMIC_IPADDR2, I find they hit as much ham (still only a little) and about half as much spam. In other words, testing the first entry of the -Untrusted pseudoheader empirically does better for my setup. I guess this is because (a) greylisting cuts out a lot of botnet spam that would otherwise be delivered direct to internal_networks; (b) this system is set to use the 3.2 model, that is, without including general ISP MTAs in trusted_networks; and setting internal_networks to only include MXs for the organisation. What spam does match these rules often comes via servers that provide MX for a domain that doesn't greylist or filter and then forwards, and these (often MXs provided by domain registrars) I include in trusted_networks but not internal, such that spam delivered to them is tested appropriately by the existing HELO_DYNAMIC_IPADDR2 and FH_HELO_EQ_D_D_D_D. BTW, when I did try including servers like Google and ISP MTAs in trusted_networks on the basis that they are "relay hosts... considered to not be potentially operated by spammers, open relays, or open proxies. A trusted host could conceivably relay spam, but will not originate it, and will not forge header data" I found not only FPs from EXT_HELO_DYNAMIC_IPADDR2 etc, bit also a lot of FNs, partly because ALL_TRUSTED often triggered. I imagine that if this is an issue, it will come out over the course of SA3.3 testing. BTW (2), maybe I overstated the case for URIBL_RED. It seems to vary somewhat in its reliability, and probably shouldn't be scored >1.0. Still non-zero though, I propose. CK
