Incoming SMTP in the year 2017 and absence of DKIM

Thu Nov 30 20:05:31 UTC 2017

On Thu, Nov 30, 2017 at 10:22:40AM +0100, Bj??rn Mork wrote:
> rDNS is not a host attribute, and will therefore tell you exactly
> nothing about the host.

The lack of rDNS disqualifies a system from being a legitimate mail host.
The lack of FCrDNS does the same.  (Note that it's usually prudent to
tempfail some of these cases in order to allow for the circumstance that
something is temporarily wonky with DNS.  Well-run mail services that
are experiencing transient issues will correct those, DNS will once
again be working, and queued mail will eventually make it through.)

The content of rDNS provides additional information, and some of
it's enormously useful: e.g., blah.dynamic.example.com is not a valid
mailhost, and immediate rejection is highly advisable.  Same for
blah.dsl.example.com and blah.unassigned.example.com and many other
patterns.  And of course depending on the expected mix of spam/nonspam
traffic at a particular mail server, there may be no need to accept any
mail traffic from blah.example.TLD for many values of "TLD". [1]

I just checked on a particular mail server that I'm working on, and in
November 2017, 62% of all messages that were rejected were disposed of
thusly because they failed rDNS/DNS-related checks.  (Which includes things
like the above as well as checking HELO, MX validity, etc.)  That means
that roughly 2/3 of the messages didn't need to be checked against a
DNSBL or anything else, reducing the load on valuable shared resources.

rDNS/DNS checks are an efficient, reliable, scalable, first-line MTA
defense -- and they're quite robust in the face of attempts to game them.

---rsk

[1] Or, alternatively, to only accept it at certain MX's designated
for the task -- ones which presumably apply higher scrutiny to such
traffic than would otherwise be employed.  This works for various
geoblocking tactics as well.