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