On Oct 9, 2006, at 11:12 AM, Douglas Otis wrote:
https://rt.psg.com/Ticket/Display.html?id=1360
There has been support on the list for ensuring a designated
signing domain mode of operation be retained as a viable option.
This added scenario clarifies that policy is able to make such
designations.
Policy's designated signing domains can independently indicate that:
1) the signature is valid for the referenced email-address.
2) the referenced email-address is also valid.
For DKIM to offer protection, there must be message annotation that
indicates when an email-address is asserted to be valid. An "all
messages are signed" may just increase the scrutiny given messages
that are expected to have a valid signature.
To better clarify how domain designation might be used:
When complying with only the "all messages are signed" assertion, the
following designation could apply:
<base-32(sha-1(big-isp.com))>._DKIM-F.my-domain.com
RR "d=big-isp.com; f=A"
When asserting the email-address is valid:
<base-32(sha-1(my-domain.big-isp.com))>._DKIM-F.my-domain.com
RR "a=my-domain.big-isp.com; f=A"
In the latter example, rather than delegating a DNS zone, agreeing
upon the publishing of key CNAMEs, or having the domain owner publish
public keys generated by the provider at specific selectors, the
domain owner has an option of independently publishing policy that
indicates the email-address is valid (a=), in addition to the
signature being valid (d=). The provider may exclusively use the key
at "my-domain.big-isp.com" for the access granted to "my-
domain.com." In this case, "my-domain.com" can assert general access
signed by "big-isp.com" offers a valid signature for their domain,
and that messages signed by "my-domain.big-isp.com" offers a valid
email-address. The difference is that the coordination required in a
delegation process is avoided, where the customer is free to make
these assertions as they desire at any later date.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
