[Top] [All Lists]

Re: DKIM's authentication "promises"

2006-11-03 13:50:37


My assumptions were very much in synch with what you wrote
below, but the qualification and explanation is much appreciated.


--On Friday, 03 November, 2006 12:11 -0800 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:

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 role.


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

(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.


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