[Top] [All Lists]

DKIM's authentication "promises"

2006-11-03 13:33:20

John C Klensin wrote:

   ...    a slippery slope relative to the
promises made to the IETF when the DKIM effort was chartered.
Those promises clearly stressed that DKIM was appropriate as a
reputation check by the delivery MTA or target user MUA, but not
as a means of authenticating senders and rejecting mail in
transit.  I think the above, in the context of the note that
apparently stimulated it, comes very close to assertion of
precisely that sender authentication and, potentially, rejection


I'm pretty sure your summary of how DKIM was characterized is accurate, but your phrasing leaves me with just enough doubt to believe a brief round of confirmation (or clarification) is need, no matter how much I might fear that it, too, involves a slippery slope.

As a small disclaimer, I'll note that what follows is intended to be responding only and exactly to your above text, and is not intended to be part the thread that you were participating in. That's why I changed the Subject line.)


DKIM associates a confirmable domain name with a message. It does not specify who may affix the name or what the name must be. Different participants in developing or using DKIM have different assumptions and/or expectations about who will do signing, but the specification details do not constrain the choice.

(Later work, on SSP, is adding capabilities that permit an authoring domain to publish some declarations about signing, but this is a separate mechanism from the base DKIM signing mechanism and is very much a fluid work-in-progress.)

The intended purpose of the confirmable domain name is to permit receivers of the message to make processing decisions, based on assessments of the name. It is common to characterize such as assessments as being based on "reputation" and it often is an entirely acceptable characterization. However the term reputation has a variety of definitions within the community and some are more constraining than would apply to DKIM.


The DKIM signing name might be the same as used in an rfc2822.From field or an rfc2822.Sender field. In that case, one might use language like "authenticating senders" but, of course, it has a rather constrained meaning.

The name might be associated with the operator of an MTA that processed (ie, relayed) the message. Here, too, the term "authenticating senders" could be viewed as valid, but again, it has a constrained meaning.

One meaning of "authenticating senders" refers to the entire author or rfc2822.sender email address. DKIM most certainly does not do that sort of authenticating. One might envision designing and a multi-stage system, that includes DKIM, that might provide something akin to such full-address authentication, but that is far, far beyond the scope of the current work. And I am pretty sure no one is talking about pursuing it (or at least not in the IETF.)

With luck, the above has not made things *less* clear.


  Dave Crocker
  Brandenburg InternetWorking

<Prev in Thread] Current Thread [Next in Thread>