On Jun 15, 2012, at 12:32 PM, Charlie Brady wrote: > On Fri, 15 Jun 2012, Matt Simerson wrote: > >>> In my experience, reverse DNS is frequently managed (or, frequently, not >>> managed) by an ISP, not by the admin of the mail server. >> >> In my experience, every ISP that provides clients with dedicated IPs >> also provides the client with the ability to manage the reverse DNS for >> them. > > My ISP (a smallish not-for-profit affair) claims to be unable to do that. > I've heard of and seen other ISPs which fail also. I agree that most ISPs > offer this service. A single exception is sufficient to say this can't be > guaranteed.
Why does this matter? Having a custom FQDN that you can manage is not required by RFC 2821 or my helo plugin. The RFC requires that you use the FQDN (and presumably matching rDNS) that's assigned to your IP as the HELO hostname. If your smallish ISP isn't capable of managing DNS properly, and you don't have a meaningful FQDN, then you use an address literal. The RFC tests in the new helo plugin are VERY low bars to clear. In the default 'lenient' mode, no DNS validation is performed at all. In RFC mode, if you present a HELO hostname, then that hostname must have SOME kind of working DNS. It doesn't even have to be a match unless 'policy strict' is chosen. Of the 40,494 messages in my logs, 22,418 of them have invalid HELO hostnames and 158 messages are using address literals. Almost half (67) of the literals are from valid users of my mail server. Which is why I don't block address literals. But I can safely do so now without causing my users problems because of the deferred rejection and auth clearing features of the naughty plugin. Of the 22,418 messages with invalid HELO hostnames, Windows based senders accounted for 18,971. Linux accounted for 3,172 more, no doubt consisting of compromised and illegally obtained VPSes. After I further eliminate the senders who had relay_client set, what's left is a small handful of valid servers using invalid HELO hostnames, like mail.es.freebsd.org, nkNNpNNmm-asmtpout001.mac.com (where the NN numbers mismatch), and lists.openbsd.org. In all of those cases, the servers DO have valid forward and reverse DNS, as defined in the helo plugin tests. It's just that the DNS does not match. Of course, there's also plenty of matching HELO hostnames with DNS that doesn't match, due to server clusters (Yahoo, Gmail, .mac, etc) and the like, which is why the no_matching_dns test only validates that the domain is the same. The false positive rate with 'policy rfc' is presently 0%. With 'policy strict', the FP rate is 0.025%. If only 2 servers had matching DNS (mail.es.freebsd.org and lists.openbsd.org), the FP rate for 'policy strict' as currently implemented would be 0%. Matt
