>> 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? (For now the best I could think of was to drastically reduce the score for these two rules, which presumably will cause false negatives.) -Marcel van der Goot
