Steve Atkins wrote:
On May 27, 2008, at 2:16 AM, Eliot Lear wrote:
- sorry - subject line error on my part (that's the only change).
Eliot Lear wrote:
In order for ADSP to be of use, it must be easily deployable by
enterprises and service providers. Otherwise, there is no point in
bothering to check for answers.
Very few senders are going to care about or be able to use ADSP.
That is as much because of the effort that will be required as anything
else.
Those senders want as many receivers as possible to check ADSP.
So, in order for it to be successful, you need a small number of well
motivated senders to publish records (a one-time effort, along with
a little ongoing, easily automated, maintenance) and you need a
large number of much less motivated receivers to check ADSP on
every single one of hundreds of millions of inbound emails, and their
myriad MTA providers to implement efficient code to do so.
The myriad of MTA providers could do an additional query based on the
absence of the record.
Given that, it's clear that for there to be any chance of successful
deployment is going to be dominated by the receivers. Simplifying
the job for the receiver as much as possible is a requirement for
getting that deployment.
If that means moving some of the pain, even a disproportionate
amount of pain, onto those few, well motivated senders then that's
a good tradeoff.
If you're wrong the protocol goes nowhere because of the myriad of
senders who cannot deploy the record. You are also binding the use of
the record in such a way that mail systems will have to consider its
absence meaningless far longer than otherwise.
The absence of a parent label check
will mean that enterprises must list an ADSP record for each and
every
DNS entry they have. It is not unusual for enterprises to have
tens of
thousands of DNS entries.
It's not unusual for them to have a deep DNS tree, either. A single
level tree walk will only benefit those enterprises who use shallow
DNS trees anyway.
It's one thing to special case each zone (typically where the deepness
goes) or level (even if it isn't a zone split). That's O(log(entries))
and far more easily managed.
The vast majority of enterprises make use of
provisioning systems that takes years to update and deploy. ADSP
deployment is now dependent on those implementations. Because of
that
ADSP adoption can be expected to lag dramatically behind DKIM. The
result will be that recipient sites will infer policy by the
existence
of records and hence implicitly implement a strict test.
Hence as things stand I expect ADSP to never be deployed,
I certainly don't expect it to be widely deployed by senders on
arbitrary
existing domains. If there is widespread deployment I expect most
of it to be on customer-facing ecommerce and banking domains, not
existing enterprise domains. Really, cisco and similar corporations
are not particularly likely phishing targets.
We're not paypal but we see our fair share. But the force and effect of
your argument is that there will now be two classes of domains. That is
where I believe we are missing the mark.
and I request
active consideration of the provisioning systems in use.
If a sender isn't prepared to do the one-time effort to publish some
DNS records, then ADSP clearly isn't important to them.
IPv6 is a one time effort too. One time costs matter too.
We're talking about many senders, and many provisioning systems – some
of which are shoe string and bailing wire, others are C code, others are
perl, some are products and others are free. This will run the gambit
from "easy to do" to "not for many years". The effort you are talking
about is in lots of code.
Eliot
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html