Lost in Reception

This is a difficult approach to take a position on. I applaud any activity to make it easier to separate good from bad, but:

• There really are too many other pressures on rDNS naming, not least the large already deployed base of billions of names, to hold out much hope for the rollout of an rDNS naming standard across more than a tiny fraction of the world’s ISPs.
• Penalising legitimate senders for the non-malicious [non-]actions of their service providers is an unwarranted harm (penalising them for malicious actions and negligent inaction by their service providers is also harmful, but difficult to avoid).

The establishing of norms for white hats to make clear their expectations about their own infrastructure is a good idea, but using these norms by a communication partner requires two additional pieces of data:

• An assessment of the integrity of the person/organisation in control of the rDNS: as soon as rDNS records meeting this norm become a means for receivers to prioritise legitimate senders, those address blocks whose rDNS is controlled by abusers will suddenly have rDNS records which meet this norm. Note that this is equivalent to the need for reputation data for authentication systems (SPF, DKIM, …).
• An assessment of the ability of the person/organisation in control of the rDNS to keep their data up to date. That the records meet the suggested patterns only tells an assessor about what was happening when the records were created, not about what’s happened since. This is likely to be a rather more difficult task to get right than, say, keeping SPF/DKIM records up to date if only because of the sheer number of records involved.

On the whole, using rDNS to aid in spam identification provides a pretty marginal gain, at too great a cost (in FUSSP terms it “Requires immediate total cooperation from everybody at once”), with too much need for additional information and with too great a false positive risk (there are whole countries where rDNS control is unavailable to access/hosting customers of ISPs) to be particularly useful.

Of course, making rDNS informative for occasional reference by administrators (as distinct from high-frequency automated assessment by software) – and keeping it up to date – remains sound practice.