On Aug 18, 2006, at 9:20 AM, Damon wrote:
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)?
- DKIM signatures clearly indicate which domain can be held
accountable for the message.
o When can the 2822.From address be assumed to represent the
recipient of this address?
o Can 2822.From policy play a role in clarifying whether a
2822.From address represents the recipient?
o Can 2822.From policy assertions extend to other domains
signing on behalf of the 2822.From address?
2822.From policy can offer assertions the 2822.From address is
validated (it is being used by the recipient). This validation can
extend beyond just the immediate 2822.From domain. This type of
validation is commonly done by third-parties in many situations. Key/
Selector assignments between a domain owner and an email provider, or
zone delegations arrangements between an email-provider and a name-
service provider represents _significantly_ greater administrative
and procedural effort than just listing a domain in the 2822.From
policy. A policy listing tactic also allows a common signature to be
applied by the email-provider for all their user accounts, even for
those where the 2822.From is outside the signing domain.
Whether the designated domain protects the 2822.From address is
something the domain owner of the email-address decides. Any domain
that is designated should be assumed to protect the 2822.From. Any
signing domain failing this protection should be removed with a
complaint submitted to a certifying organization. Unless 2822.From
policy offers greater assurances the message is from the address's
recipient, it provides little value. If only signatures by the
domain of the 2822.From can offer this assurance, then there is
indeed less need for a 2822.From policy.
When a verifier discovers a policy that indicates all 2822.From
address are always signed, exceptions must still be handled. Even
with a flag that asserts no other non-compliant services are used,
cousin and look alike domains will remain a problem. The greatest
protective value of DKIM is achieved with annotations that indicate
2822.From address is valid (per policy), and that this 2822.From
address has been recognized as a prior correspondent. This
annotation needs to happen as often as possible for greater
protection. This annotation does not require the signing domain and
the 2822.From domain match. When not matching, but where the
designated signing domain is well-known, this should offer even
greater acceptance than a matching From/signing domain message coming
from some obscure domain.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
