[ietf-dkim] Responsibility concerns with Designated SigningDomains
dotis at mail-abuse.org
Sat Aug 26 11:34:18 PDT 2006
On Sat, 2006-08-26 at 09:18 -0700, Michael Thomas wrote:
> Bill.Oxley at cox.com 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
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
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.
More information about the ietf-dkim