On 31 Jan 2015, at 17:33, LuKreme wrote:
What should I do about these warnings? Is there any reason not to
reject the IPs in question? And if not, how do I do so? mail_version =
2.11.3
warning hostname 102-253-144-216.static.reverse.lstn.net does not
resolve to address 216.144.253.102 hostname nor servname provided, or
not known
warning hostname 138-128-178-101.static.dimenoc.com does not resolve
to address 138.128.178.101 hostname nor servname provided, or not
known
warning hostname 158-33-143-63.static.reverse.lstn.net does not
resolve to address 63.143.33.158 hostname nor servname provided, or
not known
warning hostname 174-120-162-69.static.reverse.cascompany.com does not
resolve to address 69.162.120.174 hostname nor servname provided, or
not known
Those *SPECIFIC* IPs are probably not offering anything worth passing to
SpamAssassin or any other deep inspection. A quick check says they're
all on the SpamHaus CSS ("snowshoe" spammers) and the PSBL.
How about:
correctextract.com does not resolve to address 104.206.41.110
correctextract.com does not resolve to address 104.206.41.111
correctextract.com does not resolve to address 104.206.41.112
correctextract.com does not resolve to address 104.206.41.113
correctextract.com does not resolve to address 104.206.41.114
correctextract.com does not resolve to address 104.206.41.115
Yeah, those too...
But that's dodging your implied broader question:
"Should I reject mail because the name in a client IP's PTR doesn't
resolve back to the IP?
Or in Postfixish:
"Should I use reject_unknown_client_hostname?"
I can't tell you who you are...
Or what your mail server is for...
However:
Nearly every SMTP client using an IP with a PTR whose name does not
resolve back to that IP sends nothing but spam. The exceptions happen to
include some Microsoft "Hosted Exchange" servers, Google outbound
machines, and a random smattering of sloppily-managed corporate MTAs.
Some of these (especially in the first 2 sets) also send *almost* pure
spam. How pure the spam from such machines is for YOUR system, I cannot
guess.
So I'll say what I do. On my personal system, which serves in part as a
trap for spam, I do not use that rejection criteria but instead use
reject_unknown_reverse_client_hostname, which only requires that a PTR
exists. On other systems I manage, I mostly DO use
reject_unknown_client_hostname (or its equivalent for other MTAs.) In
the systems where I use that, the false positives from it are
manageable. However, there are sites where I've backed off that
restriction because the FPs were not acceptable. On the systems where I
don't use reject_unknown_client_hostname or its equivalent, I do a
little more deep analysis (i.e. SpamAssassin) which mostly catches the
spam and lets the non-spam in. Mostly. Almost perfectly, but not quite.
So: look at your logs for at least a couple of full weeks. Preferably
months. Figure out whether you have legit traffic coming from sites with
messed-up DNS and how you want to deal with that.
