Hi Andrew, thanks for posting that.
From: Paul Wilson <pwilson(_at_)apnic(_dot_)net>
Subject: MARID use of reverse-DNS
We are aware of issues in the depth of coverage in reverse-DNS, in two
ways:
Firstly, there is an ongoing 'lame' state for delegated address ranges
(of the order 20%) which we are now actively managing through a
(recently developed) lame DNS detection, reporting and cleanup process.
Secondly, the participation rate in reverse-DNS is less than 100%,
varying by country, age of network, and maturity of regional/local
Internet/ISP coordination.
I am really glad someone is aware of this and working on it. I don't think
use of PTR will be core to MARID but lack of proper rDNS has plagued
anti-spam efforts for quite some time
1) Operational Impacts
...
Should MARID require each SMTP transaction to perform a reverse-DNS
lookup, we would face an increased growth in traffic, in proportion to
the rate of in both packets and bytes/sec served, and probably need to
investigate changes to our deployment methodology in line with the root
servers, such as use of anycast DNS, and improvements in DNS zone
management to scale with the increased rate of change as the
non-delegated reverse spaces (and lame reverse spaces) scramble to
comply with SMTP delivery obligations.
This concern kind of ignores that most MTAs already do a PTR lookup -
Sendmail has had this in place for a long time.
We probably won't make PTR a key component (at least I don't think it is a
key component in any of the input proposals). Most of us are already aware
of the poor support that many ISPs offer in terms of reverse lookups. SPF
has a ptr: mechanism, so those who have proper PTR records set up might
choose to use them instead of listing all their ranges.
Speaking of scrambling to comply though, there is already pressure from
other large ISPs on users with no PTR (or non-existent name in a PTR) to go
cry to their ISP -- for example AOL has a published policy that they "may"
deny service if your mailer has no PTR.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>