From: "Marcel van der Goot" <[EMAIL PROTECTED]>
> >> 2.9 NO_RDNS_DOTCOM_HELO Host HELO'd as a big ISP, but had no rDNS
> >> 1.8 FAKE_HELO_AOL Host HELO did not match rDNS: aol.com
> >
> > These basically say that the server that gave you the message claimed to
be
> > AOL, but its IP address did not resolve to a host in the aol.com domain.
>
> I've recently had the same problem, missing a number of important emails.
My
> guess would
> be the main cause of the problem is something wrong with AOL's DNS setup.
> However, spamassassin
> itself deserves blame too: The first rule says that there was no rDNS
record;
> that's bad, so
> a lot of points are assigned. Then the second rule says that the
> (non-existant) rDNS record did not
> match AOL; well, duh!
>
> If a match of rule 1 implies a match of rule 2, spamassassin should be
smart
> enough to not even try rule 2
> when rule 1 already matches, because otherwise you get two penalties for
one
> symptom. In this case,
> the single DNS problem by itself is already nearly sufficient to cause
> identification as spam; all that's
> needed is that the sender uses html, and whammo!
>
> Is there a way to tell spamassassin about such relationships between
rules, or
> is that incompatible
> with its design?
I wonder if this might work:
meta AOL_MESSED_UP ( NO_RDNS_DOTCOM_HELO && FAKE_HELO_AOL )
describe AOL_MESSED_UP Let's not compound the felony here
score AOL_MESSED_IP -2
{^_^} Joanne
