Ok. There's a few reasons why we've been told we need this, and
they're all wrong. Let's take a look at each of them:
1. Provide the ability to transition a domain, where part is ready and
part is not.
2. Provide the ability to only sign important addresses.
These can be handled by "I sign some mail" (or perhaps just as
well with no policy at all). Then the company can sign only the mail
they want to sign.
In both of these first two cases, there is an assumption that it will
be hard for bigbank.com to get to the policy of "I sign all email",
and we should accomodate them. Granted it's hard. But we should also
be able to assume that it is worth it, and that "I sign all" is the
desired long-term situation.
A half-covered domain leaves that domain severely exposed. Suppose
bigbank.com signs for "accounts", "statements", "president",
and "investment". They would also have to try to exhaustively
cover for 1000 legitimate looking variations on those addresses, as
well as 10000 legitimate looking addresses that don't look anything
like the real ones, and almost certainly miss something, and leave
themselves open to phishing, anyway. All despite the fact that they
tried to do something that is in many ways more complicated than
full coverage.
100% coverage may be hard, but it is necessary to protect a domain.
Half-assed coverage is useful transitionally, that is all. Subdomains
are another mechanism by which bigbank.com can split up their transition,
and protect the most important addresses first, although again, without
complete coverage you can have similar problems.
3. Provide the ability to sign all addresses, but offer different strengths
of signatures, ranging from "this came from us" to "we absolutely
certify the accuracy of everything in this message"
I'm trying to make sense out of this. I'm not sure I see it yet.
What good does it do to give a particular address it's own key
if you're already signing everything? Is there some proposed
mechanism for quality assurance ratings as a part of DKIM?
I suppose one case might be the disgruntled bigbank employee
who starts generating fake messages from accounts(_at_)bigbank(_dot_)com(_dot_)
That's an internal matter for bigbank, and it isn't our job to
fix this problem. Internally, there's dozens of ways for them to
secure important addresses, including software that requires extra
verification for certain addresses, or use of subdomains to partition
off everyone from mid-management on down.
But ultimately, no scheme can completely prevent this from happening.
What if the guy that maintains DNS is the one that's disgruntled?
4. Provide the ability for users outside of a domain to send mail from
within that domain.
Again, it's not DKIM's job to solve the internal problems of a domain,
especially when those internal problems are so easily solved
otherwise. VPN is one solution, so widely available that I can
run it on my palm.
tom
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html