On 09/28/2015 02:55 PM, RW wrote: > On Mon, 28 Sep 2015 14:27:33 -0700 (PDT) John Hardin wrote: >>> # Add spamminess to "may be forged" warning in Received header >>> header RCVD_MAY_BE_FORGED Received =~ /\(may be forged\)/ >>> describe RCVD_MAY_BE_FORGED Fake HELO info in Received header >>> score RCVD_MAY_BE_FORGED 0.2 >> RE looks fine. I'd just describe it as "forgery warning in Received >> header" rather than trying to interpret *why* the warning is there.
This has existed (in sandbox form, with stats) for quite a while:
header __MAY_BE_FORGED Received =~ /\(may be forged\)/
meta MAY_BE_FORGED __MAY_BE_FORGED && !__NOT_SPOOFED && !__VIA_ML
describe MAY_BE_FORGED Relay IP's reverse DNS does not resolve to IP
MSECS SPAM% HAM% S/O RANK SCORE NAME
0 1.3921 0.1703 0.891 0.65 0.01 T_MAY_BE_FORGED
0 1.4303 0.2045 0.875 0.64 (n/a) __MAY_BE_FORGED
So this isn't the strongest of spam indicators, at least in the general
case.
> YMMV but I find that in deep received headers "may be forged" is a
> slight ham indicator. That's why I suggested limiting the match to the
> MX server's received header.
It's a spam indicator on *some* /properly implemented/ mail
infrastructures. You need to test it on your own infrastructure to
ensure that sendmail and rDNS are playing nice together. If your
infrastructure /doesn't/ add this header (this is a sendmail thing
iirc), you do not want this type of rule. Even if it does, you have the
issue of external mail servers adding this header. That's why the above
meta rule excludes mailing lists.
-Adam
--
Adam Katz
@adamhotep <https://twitter.com/adamhotep>
signature.asc
Description: OpenPGP digital signature
