I think you should stay away from terms that are known to have unresolved
trademark issues (this in in fact IETF policy for its documents if I'm
not mistaken).
There are no unresolved trademark issues with "DomainKeys" that I'm aware
of. Perhaps there is something that Miles could say here to help clarify.
As far as existing _domainkey users, clearly they will have to install new
software anyway and if they want to use both _domainkey and _dkim, its not
terribly hard - just use CNAME or NS pointing to the same zone
(far less of a problem then publishing new record).
No, no. First, updating MTA software to incorporate DKIM is not at all to
be equated with the ability to access and change DNS information. These are
not the same. As an MTA vendor I can easily and seamlessly upgrade my
customers to DKIM enabled versions. I can not change their DNS
configuration at all.
So I'm quite strongly against using _domainkey and would prefer to see
_dkim in your draft's next version (if any prefix is there at all).
This must never _ever_ be done. It would instantly obsolete the entire
deployed base of keys already in use with DomainKeys. I am just one MTA
vendor but I alone have more than 50,000 sites already using DomainKeys
enabled versions of my MTA. It was (and is) a very large educational and
"hand-holding" task to teach them (and their ISP's) how to setup DK keys,
how this "isn't taking over your DNS server", doesn't introduce unacceptable
bugs/security concerns, etc. To repeat this task _from scratch_ just so we
can use "_dkim" instead of "_domainkey" will be major wet-blanket on the
momentum for no technical reason that I can see. It would remove the
feeling that DKIM is an evolution of DK and insert the notion that it is a
completely new system entirely. Further, it is conceivable that someday the
_domainkey root can be used to store keys for services other than just mail.
Therefore, "_dkim" ("... identifed MAIL") might communicate an artificial
usage constraint.
As has been my mission since I got involved with the DK/DKIM effort, I must
continue to plea for the "little guy" - the other 50% of the email using
world that doesn't use a Yahoo, Earthlink, Hotmail, or other mega-corp ISP
as a brain hired to do all their thinking for them. This has it's place of
course, but the other half of the email world is handled by guys like me who
try to provide turn-key "in house" mail server solutions to people who "make
broom-sticks for a living" and don't even know what DNS is - to say nothing
of having access to it or expertise to manage it. For this effort, one of
the most critical aspects of DKIM is that it is compatible with the existing
DomainKeys infrastructure (selectors, keys, DNS use, etc) and we have been
preaching this to the press and at seminars with our resellers/customers,
etc. This is foundational to the work already done on the spec and nothing,
nothing, should be introduced to change that in my view.
I appreciate everything that has been done in alternatively proposed systems
such as META-Signatures and others. There are many _many_ good ideas there
but ultimately even good ideas must be rejected on the grounds that they
would alienate a substantial and extant deployed base. So, this is where I
stand (just so everyone knows). It doesn't make me right and I obviously
don't have any veto powers or anything but careful thought has gone into the
DKIM specification both technically and, frankly, politically, in order to
leverage the existing DK infrastructure. This shouldn't be tossed away IMO.
--
Arvel