Karsten Bräckelmann wrote: > Please see bug 6155 comment 128. > https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6155#c128 > > The issue persists, and being an onet.pl customer using The Bat! > MUA is kind of a deadly combination. Those are being shot > single-handedly. > > score KB_DATE_CONTAINS_TAB 3.800 3.799 3.799 2.751 > score KB_FAKED_THE_BAT 2.432 3.441 2.008 2.694
Karsten forgot to mention that the latter rule is dependent on the former rule. > Comments? Is this something we need to worry about? I do, rather > scary to me. :/ Me too. Is onet.pl the only such instance of this overlap? Why not move KB_DATE_CONTAINS_TAB to a subrule and make some kind of onet.pl-detector that the new meta must match against? They have an SPF record, though we probably can't rely upon implementations using SPF, so since it's simple enough, we could manually parse it: header __DATE_CONTAINS_TAB Date:raw =~ /^\t/ header __RCVD_ONET_PL X-Spam-Relays-External =~ / ip=213\.180\.1(?:28|[345]\d)\.\d/ meta KB_DATE_CONTAINS_TAB __DATE_CONTAINS_TAB && !__RCVD_ONET_PL # here for reference, unchanged: meta KB_FAKED_THE_BAT __THEBAT_MUA && KB_DATE_CONTAINS_TAB Still, this is bad as it assumes their SPF record is foolproof and unchanging (their use of "-all" shows that it is at least theoretically authoritative). Also, since we need it to survive mailing lists and forwarding services, we can't key an IP check on the last external relay, meaning that the passage through onet can be forged. Given some other headers, we might be able to find a better counter-filter. To attack it from another angle: has anybody (preferably a Polish speaker) approached Onet.pl and at least mentioned the problem if not also a solution? Their use of SPF implies that they care about this sort of thing...
