On Sat, 2006-08-26 at 09:18 -0700, Michael Thomas wrote: > [EMAIL PROTECTED] wrote: > > SSP goes beyond that and informs the receiver about the signing > domains practices which also allows you to potentially correlate what > to expect from the author's domain. Maybe the overall problem here is > that we're conflating the information service of SSP and the > correlation that a receiver might want educe from that. Maybe we > should say that SSP is *only* about the practices information service > of the *actual* domain in question. From that standpoint, it doesn't > make much sense for that domain to speak of the practices of other > domains -- that's their SSP record's job.
When policy is referenced only from the 2822.From domain, it should be called DKIM From Signing Policy, or DFSP. Perhaps there could be policies referenced from other message elements. Going through the trouble of verifying the DKIM signatures leaves few questions about the signing domain not better conveyed within the keys. The greatest benefit to be obtained from any policy would be about the 2822.From address. The most important piece of information to be conveyed is whether this 2822.From address is assured to be valid. Clearly this information does not risk damage to the integrity of the signature as some have suggested. Also, a list of domains that sign on behalf of this domain does not represent a relationship other domains may have with respect to their 2822.From addresses either, as you appear to suggest. This 2822.From policy, whether or not it includes a list of domains, is _only_ about this 2822.From address and no others. It doesn't make sense to preclude an ability for millions of users from having an option of being able to associate their 2822.From domain with that of a specific signing domain with whom they trust. This process is safe, easily scales, does not involve a routine exchange of keys along with incumbent unique handling of messages. When their trust is misplaced, then only this domain's 2822.From address is affected, and no others. Like it or not, DKIM is about trust and conveying an assurance only acted upon when the 2822.From address is trusted. This trust is automatically conveyed to the signing domain when the domains match. The 2822.From policy offers a means for this trust to extend to other domains. Imagine that _dfsp._domainkey.true-blue.com returned a DFSP record a=IRON-CLAD-DKIM.COM. This record conveys to the recipient that they should not be surprised to find this domain signing their messages, but also their 2822.From address is also assured to be valid. If you don't trust IRON-CLAD-DKIM.COM or the 2822.From address, then your choice as a recipient is to not accept the messages or place it in low esteem. The only damage that might occur would be to the 2822.From domain that may have misplaced their trust. IRON-CLAD-DKIM.COM will need to ensure only validated 2822.From addresses are signed, and that their domain is not used to send spam. These two tasks offer mutual benefits to IRON-CLAD-DKIM.COM, and this type of assurance adds significant value to their customers then able to freely associate this domain with theirs. The recipient of the message now has twice the information upon which to weigh their trust. That of the 2822.From address AND that of the signer. More is better. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
