On 10/5/09 5:38 PM, John Levine wrote: >> In light of the comments by Bill Oxley and my belief that the ability of >> a domain to designate signing by a specified 3rd party is useful, ... > > It would really be helpful if you two could explain WHY you think it's > useful. Given the way that DKIM works, there's only two possible > benefits from third party signatures. Say we want to have isp.com > signing for its customer a.com: > > A) a.com sends its mail through isp.com's system, a.com is unable to > sign mail before it's relayed to the smarthost, and it's too hard for > isp.com to apply an a.com signature
While it is possible for a.com to implement DKIM signing on their servers, they may not able to allow their roaming users access to their email server that resides behind a firewall access point. It is even possible that a.com's ISP does not allow them to operate an externally accessible server as stipulated in their SLA. As a result, a.com might wish to utilize the services of isp.com that signs with DKIM, and confirms a user's control of an email address before signing whenever the From header is not within the isp.com's domain. This works fine until it comes time for policy to be applied. > B) Nobody's heard of a.com, so it wants to benefit from the reputation > of isp.com. Unfortunately, that too is a valid reason for taking advantage of a larger providers size. Also add- C) To authorize mailing lists to better ensure their message's handling while asserting a policy of "all". > If you can't tell us which of these you have in mind, we're just going > to go around in circles. I don't think there's any other problem that > DKIM signatures can solve, but if you disagree, please tell us what it > is. An exchange of keys or selectors via CNAME records represents an unnecessary expense when compared to a unilateral base32(sha1(authorized-domain)) label published below the _adsp subdomain. To ensure against collision concerns, the name of the intended domain can be also included within the resource records as well as the domains policies regarding this domain. Such as: _HGSSD3SNMI6635J5743VDJHAJKMPMFIF._adsp._domainkey.example.com. IN TXT "tpa=isp.com; scope=F;" This authorization scheme would not require isp.com to change how they currently handle their email or sign with DKIM. Such an authorization scheme scales and could better ensure the handling of messages from mailing lists, when more stringent policies are being applied. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
