Eureka! Problem solved/hacked/understood/whatever.
a) My MTA is crap, and puts the HELO name and IP in the received header, but
no rDNS.
a1) This P.O.S. MTA has an option to "Check rDNS". It will check for you,
and then return "SUCCESS" or "FAILURE" on the existence of a PTR or A record
(does not look at the CONTENTS of the record!#?! ), but does not report the
findings in the header at all. What were they thinking?
b) SpamAssassin at 3.1.7 parsed these headers incorrectly making
whitelist_from_rcvd operate on helo names. Operate very effectively, I might
add.
c) For now, I've hacked Received.pm (17 lines before the final call to
make_relay_as_string; line 1226 here) with:
# Hack for stupid MTA that DOESN'T put lookup in header
if ($rdns eq '') {
$rdns = $helo;
}
d) Most of you guys are going to say "Get a decent MTA". Some of you might
say, there may be lots of folks whose whitelist_from_rcvd quit with 3.2.3.
My question for the latter group is: "Should I submit an enhancement request
to have a whitelist_from_helo added to SpamAssassin? It's far stupider than
whitelist_from_rcvd, but far more useful (based on my previous results) than
whitelist_from (until the spammers read this note, that is<g>). A mass
change of whitelist_from_rcvd to whitelist_from_helo is far easier than
rolling out a new MTA for all my clients (although I should do that anyhow,
huh?).
e) Can we get SpamAssassin to optionally do the rDNS lookup? The IP is
there. The comment in the source, "we know the MTA always does lookups", is
obviously incorrect.
f) Note to the botnet folks - botnet uses the helo name too! And it's not
using what SA parsed. I guess it's reparsing the header itself
wrong/different/enhanced.
Dan
My Headers
Received: from helo.domain.tld [0.1.2.3] by mail.visioncomm.net ...
"Correct headers"
Received: from helo.domain.tld (rdns.domain.tld [0.1.2.3]) by
mail.visioncomm.net ...
