On Fri, 4 Mar 2016 09:08:46 +0100 Matus UHLAR - fantomas wrote: > >> On 03.03.16 16:54, RW wrote: > >> >RCVD_NUMERIC_HELO is an independent deep check and overlaps > >> >heavily with either FSL_* rule. > > >On Thu, 3 Mar 2016 17:59:33 +0100 > >Matus UHLAR - fantomas wrote: > >> I wouldn't say so, at least on my system. > >> > >> % zcat /var/log/mail*.gz | cat - /var/log/mail /var/log/mail.1 | > >> grep RCVD_NUMERIC_HELO | grep -c FSL_HELO_BARE_IP 5 > >> % zcat /var/log/mail*.gz | cat - /var/log/mail /var/log/mail.1 | > >> grep RCVD_NUMERIC_HELO | grep -vc FSL_HELO_BARE_IP 36 > > On 03.03.16 17:53, RW wrote: > >That probably because in mailing lists you can have RCVD_NUMERIC_HELO > >on its own. > > > >What do you get the other way around? FSL_HELO_BARE_IP without > >RCVD_NUMERIC_HELO. > > Ok, filtered a bit more > 1x FSL_HELO_BARE_IP (also hit RCVD_NUMERIC_HELO) > 14x RCVD_NUMERIC_HELO > > that doesn't tell much about proper score, but they don't overlap ;-)
What I meant was that everything that hits FSL_HELO_BARE_IP_* hits RCVD_NUMERIC_HELO and so when considering the relative scores assigned for deep and last-external you need to you need to take account of the score generated for RCVD_NUMERIC_HELO. That is consistent with your one FSL_HELO_BARE_IP_* hit. I get complete overlap, presumably, because I don't run mailing lists through SpamAssassin (FSL_HELO_BARE_IP_2 has an exclusion for mailing lists). I didn't anticipate that they would be such a big source of RCVD_NUMERIC_HELO hits. Perhaps there is a place for RCVD_NUMERIC_HELO to score the deep hits that are excluded from FSL_HELO_BARE_IP_2. OTOH it may be that the optimization is ill-conditioned. I think it might better all round to replace RCVD_NUMERIC_HELO with meta FSL_HELO_BARE_IP_3 __FSL_HELO_BARE_IP_2 && !ALL_TRUSTED && !FSL_HELO_BARE_IP_1 && !FSL_HELO_BARE_IP_2
