On 8/18/06, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org> wrote:
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.
In this case the 2822 and the 3rd party have an established
relationship. However, in my opinion, in some cases I may only be able
to control this using a 2822 policy to supersede any 'common'
signature that may be in place.
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.
Agreed.
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.
Unless 2822 is a "I Sign All"
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.
How so?
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.
This is a way to fix something that is broken through the use of
software. I will start writing some now... just in case.
The greatest possible protection comes from the 2822.From having
granular control over whom may sign and when and from where a
signature is required, . (which we can't do right now).
Regards,
Damon
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html