There's something about DKIM that I think needs to be stated again,
as it often gets lost. There is a potential problem that any sort of
digital signature can become a tracking system.
Email already has problems with not being as privacy-friendly as it
should be in an ideal world. For example, it's possible from this
message to know where I am to a reasonably small area. It doesn't
take the powers of Sherlock Holmes to infer a good deal more about
what I'm doing this week.
Digital signatures also have weird side-effects that are not privacy-
friendly. If Alice sends Bob a signed message with tart comments
about Charlie, this can come back to haunt her in ways that mere
plaintext would not. On top of this are issues of how much a
signature may or may not imply a legal commitment
When we first created DKIM, we worried about the interactions between
these things. We didn't want a signature-based email authentication
system to become a tracking system that makes the loss of privacy
coming from electronic communications even worse. There are a number
of facets of DKIM that reflect this desire.
For example, DKIM is a *domain* level system, not a *user* level
system. Part of the reason is to protect the end users. More
precisely, it is to permit the administrative domain to protect its
users. There are other reasons it's a domain-level system, too, but
let me focus on this one.
A DKIM signature says nothing about the user because the user didn't
make it. It can't be mistaken for a commitment. It doesn't introduce
new disclosures of private information. This is not an accident. It
is not a bug. It is an intentional feature.
This feature has some ramifications. One of these is that the actions
of a bad user affect the opinion receivers will have of an
administrative domain, and this affects the good users in the same
administrative domain. But there are ways that the managers of that
system can do interesting things. These are allowed, but orthogonal
to the basic DKIM. For example, a large ISP can use selectors to put
"good" users under the aegis of different set of keys than the less
good users.
Another ramification of this is that the end user has no control over
this. This is the flip side of the above. If I put [EMAIL PROTECTED]
in a different key than [EMAIL PROTECTED], Goofus has to lump it or
pack up. But we want this! It is again, a *feature*. If DKIM didn't
have this, then commercial ISPs couldn't use it.
Yet another side-effect of this is that the receiver is kept out of a
lot of intra-domain policy and politics. They can use emergent DKIM
systems without needing to get involved in actual sausage factory
behind them.
There is also a dark side of this. An ISP can send email on a user's
behalf. An ISP can put in i= a string that the end user does not
like. These are not bugs, they are not omissions. They are
intentional features. But they are also not problems that exist
because of DKIM. An ISP can rewrite the headers of a mail now.
On my work mail system, I send out mail with the address of
[EMAIL PROTECTED] My server rewrites that to [EMAIL PROTECTED], and it
pisses me off. However, this isn't an issue between me and RFC n, it
is an issue between me and the admins of my mail server. There's
nothing today that prevents an ISP from slurring an end user by
putting obnoxious notes in their address. (E.g. goofus+spamming-idiot-
[EMAIL PROTECTED]) It isn't even interesting
to think of ways that an administrative domain can annoy or defame
the end users.
But these aren't DKIM problems. They are email problems. Heck, I'd
argue that they aren't even problems, they are situations. But
whatever they are, they're beyond the DKIM standard itself.
Similarly, there are ways that an evil ISP can break the very privacy
protections that are part of DKIM. But they aren't our problem, here
in this working group. I think it is wrong to do user-level keying,
because it has bad privacy characteristics. But in your domain --
knock yourself out.
To sum up, please do not lose sight of the privacy protections that
are in DKIM. They are there for a reason, and they are agreed upon as
part of the consensus of this working group. DKIM is not a user
authentication system. It is not a protocol that forces
administrative domains to be good actors. This is by intention and
design.
Jon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html