On Apr 27, 2008, at 9:46 PM, Jim Fenton wrote:
Why not depend upon discovery records? How many public message
exchange protocols beyond SMTP will use ADSP records? Who even
expects widespread adoption of ADSP? Why would it be difficult to
provide ADSP coverage predicated upon the existence of SMTP
discovery records? The lack of MX records should also preclude the
use of ADSP.
Discovery records for SMTP are both MX and A, and that isn't
changing. My point is that there are far too many A records in many
domains for it to be practical to publish an ADSP record to go with
each one, lacking tools to do so.
Domains benefiting enough to publish ADSP ALL policy at every node are
likely to remain in the minority. A publishing convenience that
depends upon receivers walking up two domain levels adds unnecessary
DNS transactions for all emails, and exposes second level domains to
undesired transactions that are beyond their control. Higher
processing overhead occurs for each email, where the majority are
undesired. Minimizing associated overhead in the face of massive
undesired messaging is the _only_ means that might help ensure broader
ADSP receiver adoption.
Until deprecated for SMTP public interchange discovery, the only
practical solution would be to include ADSP records at every node
containing A records. When publishing A records is possible, so is
publishing ADSP records. ADSP's use of large text labels should be re-
examined with respect to an unnecessary impact on zone sizes. DNS is
not intended for human consumption.
And a requirement to deploy new DNS tools will hinder coverage
greatly.
Rather than tools, better definitions are needed for the name space
used with SMTP and ADSP. Public SMTP interchange should be able to
impose possible MX requirements as a local policy option during
reception. In addition, the lack of MX should also preclude ADSP
related transactions. SMTP must remain functional for deployments
where DNS is not used, not related to public exchanges. Such
functional differentiation seems well suited to the application of
local policy.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html