Wietse: > I like this. This is very close to what I want: signed mail that > speaks for itself, whether it's first-party or third-party signed.
Dave Crocker: > and just to make sure *I* understand what you mean: mail signed by the > author, > or mail signed by an operator? Wietse: > Whether the signing domain is the author's domain (1) or whether > the signing domain is an unrelated domain (2) > > (1) Secret key with the author, or delegated to author's ISP. > (2) A mailing list operator, an operator that stamps mail as > "no known virus present", or some other transit service. Dave Crocker: > right. > > (1) uses a domain directly associated with the author domain. > > (2) uses some other domain (that is associated with the operator doing the > signing.) I see where the confusion comes from, namely the scenarios where both (1) and (2) involve a third party. To clarify myself a little further: 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html