On 6/2/2010 12:58 PM, MH Michael Hammer (5304) wrote:
Since we've been seeing reports of breakage due to using ADSP records for
domains that are not under sufficient control, it is clear that some
fraction of the ADSP-using world does not understand what it is for, or at
least what its limitations are.
If we apply this to other standards (SMTP, DNS, HTTP, etc) we would just
have to power down the whole internet. The best that we can do is come up
with something that makes a modicum of sense, fix things we didn't anticipate
or understand because we needed operational experience and move on.
There will always be some fraction of the user/implementer base that won't
understand protocols, standards or RFCs. It kind of goes with the territory.
Mike, this is the sort of discussion disconnect that prevents making progress.
I'm copying the list because it's a broad-based problem we are all having in
trying to discuss issues.
First, a question was put forward and I offered an answer. It is simply not
fair to then respond in a manner that dismisses that answer (or at least
dismisses it in this way.)
Second, the usual way that services get successful is to look for problems in
their use and look for ways to correct them. Simply saying that there are
always some problems is not helpful.
Third, we do not have massive amounts of ADSP success which permits
marginalizing a tiny amount of problems. We have tiny use, with notable
breakage.
Fourth, it has become increasingly clear to me, at least, that there is
broad-based misunderstanding of what can reasonably be accomplished with DKIM
and what can reasonably be accomplished with ADSP, versus what cannot. Failure
to gain broad-based agreement about both capabilities and limits ensures an
on-going mismatch in expectations.
If proponents want simply to keep automatically saying that things are great
and
keep automatically rejecting any counter-points, then I'm not clear what the
purpose of these discussions is.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html