Damon:
> > In (1) the public key is listed under the author's domain, while
> > the secret key is operated either by 1a) the author's MTA or by
> > 1b) the signing party's MTA. This is what I called a first-party
> > scenario above. The verifier can't distinguish between 1a) and 1b)
> > except by parsing the contents of Received: message headers.
> >
> > In (2) the public key is listed under the signer's domain, and the
> > secret key is operated by the signing party's MTA. There is no
> > relationship between author-domain and signing-domain. This is what
> > I called a third-party signature above.
> >
> > In both (1) and (2) an assessment can be made on the basis of the
> > the signing-domain. If I get mail with a signature from some no-name
> > signing domain, then the author-domain (rfc822.from) is mostly
> > irrelevant. And if I actually do have reasons to trust the
> > signing-domain, then the author-domain is mostly relevant in case
> > (1), and mostly irrelevant in case (2).
>
> Wietse,
> Thank you for the clearest definition I have seen to this point.
> What is the mechanism for depreciating (2)?
In case (1), when the trusted signer-domain matches the author-domain,
I might trust that the mail actually originates from the rfc822.from
domain. In case (2), when the trusted signer-domain is not related
to the author-domain, I might trust that mail was distributed by
the mailing list that I subscribe to, or that it was processed by
the malware removal service that I subscribe to. Thus, in (2) the
author-domain (rfc822.from) is relatively unimportant compared to
the signing-domain; even in (1) its importance is only secondary.
Wietse
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
