[ietf-dkim] The mystery of third party signatures
doug.mtview at gmail.com
Tue Oct 6 11:47:48 PDT 2009
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.
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
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.
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.
More information about the ietf-dkim