Eliot Lear wrote:
John,
I think we're rehashing an earlier debate, but...
I realize there are organizations with uncooperative DNS managers who
make it hard to install the key records needed. I wouldn't be
surprised if some of us even work at such organizations. But a local
optimization that ends up demanding extra work from the rest of the
world to work around one's DNS management is, to put it mildly, not a
great idea. If DKIM is going to be deployed, part of the deployment
will be to figure out how to get the required records installed.
This isn't quite a fair characterization. It's not *just* uncooperative
DNS managers, but software limitations, differing budget lines, actual
distinct operating entities where DNS is offered as a service, etc. I
would expect that this problem is likely to persist in nearly every S&P
500 company, a number of governments and educational institutions. So
when you call this a 'local optimiziation', maybe it is true in the
academic sense, but the scope of the locality is quite large.
+1, I think it isn't as much as being uncooperative but lack of
understanding, the unsureness to commit, the cost prospects. DKIM
seems so pathetically simple, yet beyond understanding but by only a
small set of people. It is both an expensive project and product
engineering effort. Never mind the selling of it isn't so cut and dry
either. At this past IETF meeting, I joined the WebEx meeting with
the audio streaming, and I also invited two customers who have
expressed interest in DKIM listen in as well. You don't want to hear
the comments one of them gave to me, and the other (an IT manager of a
major store chain anyone with kids have visited) decided right then
and there DKIM is not ready and had doubts it will ever be ready.
Part of the problem is that it hard to see what does it solve as it
currently define. What problem does it address? DKIM lacks a sound
description for what is the payoff. The term "responsibility" is,
well, quite flaky and for managers that have concerns with product
liability, using the term responsibility raises questions. It creates
some confusion about who owns want and what responsibility means. I
don't think this is a term that can intently left ambiguous. I believe
it has lowered the incentive to implement, like maybe putting in the
effort to write the DNS management component that is so necessary to
get this right with customers. When one begin to get serious about
looking at DKIM, like John pointed out here and in the DKIM-OPS list,
the issue of how to get DNS records added/updated in "easy" fashion
becomes rather apparent.
If DKIM does take off en masse (widely), of course we would like the
ISPs with their current DNS Web Management tools to add DKIM key
generation support But thats a manual process. DKIM needs automated
updating concepts. Its not like SPF where you essentially do it once
and you're done.
It may end up as one solution by a "DKIM provider" to have their
customers install special DKIM/DNS clients on their computers, pretty
much like a DNS2GO service and others like it that allows secured
automated updating of records on the vendor DNS server.
In fact, I can see an I-D to help provide a guideline for DKIM/DNS
Record Management, summarizes the issues, the current tools and
methods, update protocols and to maybe lay the groundwork for
developing consistent automated tools.
I also see an I-D that isn't as abstractly detailed as the deployment
guide that helps with migration. For example, a SMTP vendor can add
ADSP/DKIM verification support before it can properly offer DKIM
signing support.
Our migration plan was always to do:
1 - POLICY first at some basic level
2 - DKIM VERIFICATION 2ND
3 - DKIM SIGNING
In my technical opinion, policy helps justify the verification.
Without policy, its becomes a little harder to accept. Something has
to provide a valid reason to do this verification overhead.
The signing is the hardest part because for us, it will require a
revamp consideration of many parts. Some parts we can get rid, but
nonetheless an expensively project to commit to. I'm sure its not an
issue for the Big Bucks people here, but it is for me and and don't
wish to speak for others, other smaller systems and vendors isn't
going to have a easy time as well. <g>
--
Sincerely
Hector Santos
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html