I am not necessarily advocating that this be added to DKIM base. My ox isn't being gored on this issue but I recognize that it may not be as resolved as Dave states. It may not always be as simple as Dave indicates for senders and signers to "coordinate" in the manner he suggests.
To the extent that it is currently more difficult than less for ISPs and ESPs dealing with a lot of domains that belong to their customers, I still believe it is worth considering this revisiting this issue. This is not quite the same as an ACL in the commonly used sense. I view it more as a simple statement..... this domain signs for my mail as if I signed it myself. Mike > -----Original Message----- > From: Dave CROCKER [mailto:d...@dcrocker.net] > Sent: Monday, October 05, 2009 10:45 AM > To: MH Michael Hammer (5304) > Cc: IETF DKIM WG > Subject: Third-party "authorization" > > > MH Michael Hammer (5304) 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, I'd > > like to see this included in the update. > > > Such an addition is the equivalent of adding an access control list (ACL) > to > DKIM. This was debated extensively before and the working group noted that > an > adequate control mechanism already exists in DKIM: selectors. > > At its core, this change seeks to have recipients enforce authorization to > use > DKIM by an agent that is within the a "sender's" sphere of control. Even > though > the agent is an independent actor, they have an arrangement with the > sender and > are therefore within their sphere of control. ACLs are a significant bit > of > mechanism. > > Rather than invent an entirely new mechanism that adds to the complexity > of the > recipient's DKIM handling, the same level of useful information is > imparted by > having the sender and signer coordinate so that the signer uses a selector > for a > domain (or sub-domain) of the sender. > > This moves the work to (only) the folks who have the clear need and > motivation, > and it requires no additional changes to DKIM. > > However what this repetition of a resolved item does suggest is that we > ought to > generate a document that gives specific details for specific scenarios, > beyond > what is already in the Deployment document: > > <http://www.ietf.org/id/draft-ietf-dkim-deployment-08.txt> > > Apparently, the detail in its sections 6.3 and 6.4 isn't sufficient. > > d/ > > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html