Hi Steve, In my opinion, the first and fourth statements are not necessarily in conflict. A reputation system based purely on reverses is pretty broken. Also, it is not necessary to use it as a factor in calculating a very reliable reputation. I'm having trouble seeing how the first and third are in conflict as well, but I may be indexing statements differently. Regarding the second, you're absolutely right. It's not your responsibility if a 3rd party doesn't have a rDNS entry (at all or non-generic), however the reality is you're going to have to deal with it anyway. If your customers allow you to tell the senders to buzz off and fix it, that's terrific. However, you're in a more authoritarian (IT-wise) environment than most I would suspect. Also, you risk hurting your customers. As an example, it's not a suitable answer to our law firm customers who are critically-dependent on receiving e-mail from hopelessly broken senders.
As for the third, well, now you know why I use generic rDNS detection to defeat bots. As you say, "It's not that hard for a bot to figure out [any infected host]'s reverse entry and use that for its HELO". In fact, that's exactly what many of them do, when they're not forging well known services or sending unqualified/unresolvable strings in HELO/EHLO. And that, in itself, is responsible for over a fifth of our SMTP-time spam detections (and rejections, so there's no outscatter, unlike with a wide variety of "antispam" appliances, such as Barracudas). It's a sensible and sane perimeter defense tactic, far better than what I see most doing.
It's not disputable that rejecting generic rDNS hits (or failures depending on your point of view) will gain you benefits. What I think is disputable, is the benefit to false positive ratio. About 60% of our botnet analyses show unqualified, or outright out-of-spec HELOs. One can catch the remaining 40% through correlation of certain SMTP factors with the results of content-analysis. Near real-time data mining of both informational inputs shouldn't be underplayed. Lastly, I fully agree one should reject as much as possible before the SMTP session ends. Whether or not rDNS is a good anti-spam measure for you entails a lot of factors. I posit from our own statistical analyses the benefit to pain ratio issue is not high enough. Particularly, when there so many other correlations you can run that have lower false positive rates. Best Regards, Jason