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.