On Thu, 2006-09-28 at 22:19 -0700, Jim Fenton wrote: > So the question is, do we need both delegation and designation? > > My opinion, if it isn't already obvious from the above discussion, is > that designation is a flawed way of delegating signing authority. I > don't like the fact that example.com can hire exampletwo.com to send out > a bunch of bulk advertising, and then when there are objections, > effectively finger-point and say "Exampletwo did it". If example.com > wants mail sent by exampletwo.com to be treated as if it came from them > (first-party signature), they should be willing to take responsibility > for it themselves. If they don't want to take that responsibility, they > should accept that exampletwo.com applies a third-party signature.
The delegation process may be the provider routinely offering public keys to their customers for publishing at specific locations, or the customer delegating zones at or below their "_domainkey" label to one or more providers. This delegation process represents an undesirable level of complexity involving a significant amount of detail among several entities when it can be avoided. Beyond the complexity, delegation in this manner has other significant down-sides. You allude to DKIM being used for reputation, but it remains conjecture whether a digital signature that does not identify the SMTP Client, and can not prevent replay abuse is even suitable as a basis for conventional email reputation. Trust is a differ matter discussed further down. What is not conjecture is that DKIM will facilitate abuse reporting to the signing domain, and that IP based reputation will remain the predominate basis for conventional email reputation for sometime. Here DKIM allows the provider noise-free abuse feedback. They are sure to be informed of damage a customer may be causing to their IP address reputation. With DKIM, what is sure to matter is who should be informed and receiving abuse feedback. Reputation is likely based upon unsolicited bulk messages where DKIM offers no assurance of even indicating who might be at fault. Another concern is easily as serious is that of trust. When a provider does not adequately safeguard account access, or properly secure systems filled with "other people's private keys," there can be significant damage created for the email-address domain owner when messages of a criminal or highly questionable nature receive their signature, while they have never seen the content or have logs of what and to whom. As for designation- The draft that was just published illustrates two different signing roles can be designated, also accompanied with local-part constraints. All the same features, but with far less effort. One role would be that of a domain only offering valid signatures, but without the email-address being assured valid. This would be roughly equivalent to a signature lacking the 'i=' parameter while still fulfilling an "All Messages Are Signed" assertion. Another designated role could operate in virtually the same manner as that of delegation. Rather than matching keys with accounts, the provider would match email-address domains with accounts. Rather than establishing a complex delegation process, the account would validate control of the email-address being used. This validation process can be automated and is fairly common in many other applications already. By using a designation process, the email-address domain owner controls assertions regarding the validity of the email-address. A provider might be used for less critical communications where delivery is of greater importance. Consider that DKIM offers scant protections without annotations. These annotations should permit the recognition of valid sources, AND valid email-addresses. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
