[ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

Eric Allman eric at sendmail.org
Tue Aug 9 15:45:15 PDT 2005

> I would have thought that validating something that the user
> actually sees would have been a primary goal?

Not directly.  The signature has an identity associated with it; that 
identity (in the DKIM-Signature header field) is not displayed to the 
end user, at least in the current generation of MUAs.  However, we 
fully expect (and encourage) verifiers to have some sort of policy 
for associating a right to use a visible with the signature identity. 
Such association should be driving by the Sender Signing Policy 
(SSP).  There is one escape clause: if the signing identity is 
identical to the identity in the From header field, the verifier 
doesn't have to consult the SSP.  Since we expect this to be the 
usual case, it should substantially improve performance.

For example, a domain might be willing to permit a Trusted Third 
Party (TTP) to sign on behalf of that domain.  Similarly, large 
companies often have several-to-many domains (e.g., movie producers 
that buy domain names for each movie); they may do promotional 
mailings under a domain name different than the individual vanity 
domains.  More prosaically, a sender may wish to assert that they do 
(or do not) permit Sender header fields that differ from the From 
header field.

So although we /do/ expect that the user will see useful information, 
it isn't part of the base spec.  Indeed, in a world with good 
reputation systems, it may be that the signing identity will be used 
solely for automated filtering --- if the message is signed by a 
player known to be honest and upright and a non-spamming, 
non-phishing pillar of the community, that may be good enough, and is 
actually more friendly for the naive user who just wants their 
mailbox to be clean.


More information about the ietf-dkim mailing list