7

This probably should be a wiki, not entirely sure. Before I begin, the external server that performs scanning is a custom amavis/postfix/fortigate pipeline; it is suggested that any changes work within that environment.


I have enabled reverse lookup rejection for my work's email server, to reduce the inflow of spam being received by management. Yes, this was a management request, no pointy hair jokes please. In this regard, it is very effective, reducing the workload for our scanners by about a factor of 2 or 3. Turning it off is tantamount to professional suicide; please do not suggest abandoning it as a solution.

The problem is rather simple: lots of legitimate senders, either as vendors or customers, outsource or minimally set up their email services. The service providers are looking to turn a buck on the thinnest, smallest provisions possible, so they really don't give two hoots about getting their services fully compliant. That, or the customer/vendor has never heard of reverse lookup and can't be bothered to fix their DNS zone (or in some cases, they don't even control their DNS, which is a topic for another day). This is really a simple fix, they just need to create a reverse lookup record that matches the connecting IP address. It doesn't matter that the hostname or domain name of the server do not match the sender's domain, it only matters that the lookup for the server completes a "round trip" from IP->name->IP.

I don't have all day to chase every single one down and make a phone call, and frankly some of them won't take kindly to being pestered over the phone. But the number of broken servers out there is astounding, and not a month goes by that the "special exception reverse-lookup bypass list" grows with a few new IP addresses.

So the question is what is the best way to notify legitimate senders that their email is basically broken and needs to be fixed, without entirely cheesing them off? Is there some way to automatically notify them, so they get the information they need instead of the bland reject message that they will never bother to read? (I guarantee that 99% of the customers and vendors are non-technical and simply see it as "well it's your email server that's broken")


After some further discussion in chat, I went back to review the configuration file in use, and I think I've found a part of my grief. The following option is being used:

http://www.postfix.org/postconf.5.html#reject_unknown_client_hostname

According to that page, this option has strict requirements, and so I presume as a result, it causes some false positives.

  • 1
    here is a non-authoritative source for those with questions about this process: en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS – Avery Payne Jun 21 '16 at 18:29
  • 1
    Anyone who has never heard of reverse lookup shouldn't be operating their own mail server, they should outsource that as well. – Barmar Jun 28 '16 at 18:40
  • There's more to the post, namely that I had it enabled for several years but had to turn it off due to complaints from senders. Only as spam has increased has there been enough "pain" to justify turning it back on, and with a whitelist it's usable, if not practical. For example, people on outlook.com have no idea that they are using a non-compliant service. For that matter, many outsourced services are not compliant. It doesn't take much beyond a correct MX record + reverse ptr, but I have yet to see it done. – Avery Payne Jun 28 '16 at 22:30
  • I just sent a test message from outlook.com. The IP was 65.55.34.82 and it has valid rDNS. – Barmar Jun 29 '16 at 5:06
  • Unfortunately, that's not the case that I was talking about. Mail sending directly from outlook.com isn't the problem, people trying to pass off outlook.com mail servers as their own mail servers by giving them fake names is the problem. – Avery Payne Jun 29 '16 at 15:25
2

exim can detect the presence of the A record && absence of the PTR record with ACL and then any action can be performed via routers. $sender_host_name, $host_lookup_failed and $host_lookup_deferred do all the trick.

The problem is that spammers are often use such poorly configured but still legal hosts for submission (ISP's dynamically addressed clients f.e.). So most of notifications will be addressed to the spammers.

The easiest way to avoid useless traffic is to accept such messages, check them against AV/SA/bayes and send notification only if they have passed DATA-checkout.

In terms of exim that mean that only if $sender_host_name is non-empty, $host_lookup_failed = 1 and $spam_score_int is less than threshold, you have to issue the notification. May be content-scanning tolerance should be significantly lowered for those messages.

Unfortunately I'm not familiar with postfix enough to propose an equivalent solution.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.