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.
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.