I confess that I don't understand the advantages of using something
like HTTP to retreive the keys. Being TCP based, it sounds pretty
heavy weight.
From a network traffic point of view, a query can be a UDP round trip,
which DNS does, or a single query and response via TCP, which HTTP
does. There's nothing I can see in between unless you want to invent
an all new UDP based service just to return keys. HTTP is faster than
SMTP because HTTP only uses one query/response while SMTP has a
minimum of three, one for the EHLO, one to do something, and one to
QUIT.
There will definitely be an HTTP based key-fetching mechanism someday
for use with DKIM. It's beneficial especially for customers like
mine who are SMB organizations without direct access or special
knowledge about DNS. Imagine trying to do per-user keys or even
per-domain keys that expire frequently using DNS as the key server.
Now imagine having to do that for a company that doesn't run its own
DNS and has to ask their ISP every time they want a change. ...
I understand your problem, but your problem is not my problem. We know
that doing DNS queries during SMTP sessions doesn't have any killer
performance problems, since we've been doing dnsbl lookups for years. We
don't have much experience doing http lookups during SMTP sessions other
than SMTP callbacks which aren't all that popular, and there might be
performance problems that make them impractical. (One immediate effect is
that they double the number of TCP sockets needed.) I know that Cisco did
some IIM experiments with HTTP key lookup, but I don't know how extensive
they were or if they evaluated the performance. Recipients might have to
say tough noogies, we're not willing to take a severe hit to SMTP
performance just because your users don't have their DNS under control.
For your situation, I'd suggest shipping an optional little DNS server
with your MTA that only serves the DKIM keys, and telling your
customers that they have to tell their DNS provider to delegate
_domainkey.whatever.com to it. That's a one-time DNS change that even a
fairly incompetent DNS provider should be able to do.
Standards processes work best when they standardize existing practice.
That tells me that we only do DNS key distribution in the first
version of DKIM, and we encourage people to experiment with HTTP. If
we find that HTTP works and solves problems better than delegating the
_domainkey subdomain, then it'd be time to look at a standard.
R's,
John