DKIM's authentication "promises"

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.
John,

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.)
Anyhow...

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

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.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net