DevHeads.net

Question about logging mismatched DNS in submission server

Lately it looks like some zombie bot farm is connecting to submission
(and looks to do nothing except connect), causing many of these in the
logs:

Oct 28 06:15:35 mail postfix/smtpd[12941]: warning: hostname x.y.z does
not resolve to address 11.22.33.44: Name or service not known

For submission service where clients often connect from dynamic IP
address ranges, maybe seeing these is not important - just noise, so I
am curious about why postfix is logging this. Does this mean client is
somehow attempting to send before (without) doing any AUTH? I tested by
hand and MAIL FROM result is "530 5.7.0 Must issue a STARTTLS command
first". I found that I neglected to override smtpd_sender_restrictions
in the submission service, but it shouldn't matter if the client cant
AUTH, right?

Or is it default postfix behavior and I can ignore these logs?

Comments

Re: Question about logging mismatched DNS in submission server

By dev rob0 at 10/29/2017 - 08:35

On Sun, Oct 29, 2017 at 07:28:24AM +0000, MRob wrote:
BTW there is absolutely no need to mung such logs. Who are you
trying to protect? Also, if this is in fact on submission, why is
there no " -o syslog_name=postfix/submission" override to help
distinguish submission from smtp?

TL;DR yes, ignore these.

Postfix smtpd(8) by default looks up the PTR for every connecting
client address, and then tries to validate that PTR with an A/AAAA
lookup of the hostname value. Your example failed in validation;
"x.y.z./IN/A" (or AAAA) lookup had an error.

You can disable these reverse DNS lookups, and specifically only for
submission, but that's probably not desirable, because then every
Received: header in submission would show "unknown[ip.add.re.ss]".

The reason for logging is that Postfix logs every error condition.
The same smtpd code which listens on submission is also listening on
port 25, and there, wonky lookup results are likely to indicate a
problem of some kind.

Best bet is to just leave the defaults in place and perhaps do
filtering when reading logs, to avoid the entries you do not
care/need to see.

Re: Question about logging mismatched DNS in submission server

By Wietse Venema at 10/29/2017 - 08:21

This is logged because it affects name-based Postfix features such
as check_client_access, check_client_ns_access and so on. Without
such logging, trouble shooting after-the-fact would be harder.

Instead, Postfix could log

warning: client hostname unavailable for check_client_access:
hostname x.y.z does not resolve to address 11.22.33.44: Name
or service not known

And that would be logged for each affected feature, i.e. multiple
times per SMTP session.

If the presence of the line in the logfile bothers you: use grep.

Wietse

Re: Question about logging mismatched DNS in submission server

By Bill Cole at 10/29/2017 - 03:57

No. It means that the PTR record in DNS for that IP address resolves to
a name that does not have an A (or CNAME+A) record resolving it back to
the same IP. Not really a major issue.

Right.

Yes. Note that this is a warning only. It's an indication that parties
in control of the reverse DNS for the IP address and the forward DNS for
the name it resolves to are not cooperating with each other in a useful
way at the moment. Maybe bad luck (something out of their control is
making YOU see the name->IP resolution fail,) maybe carelessness or
incompetence, maybe a lame attempt by a spammer to misdirect blame. It
is slightly more likely that mail offered on such a connection is in
some way illegitimate, but not to a useful degree. For example: nearly
all of the connections I've see with such warnings this week either were
to impatient to get past postscreen's 6-second delay OR were blacklisted
widely enough to die in postscreen OR ultimately delivered perfectly
legitimate & wanted email.