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.
eric
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim