Perhaps the appropriate answer might be an update or addendum to best practices document or an informational document.
Mike > -----Original Message----- > From: Dave CROCKER [mailto:[email protected]] > Sent: Monday, October 05, 2009 11:06 AM > To: MH Michael Hammer (5304) > Cc: IETF DKIM WG > Subject: Re: Third-party "authorization" > > > > MH Michael Hammer (5304) wrote: > > I am not necessarily advocating that this be added to DKIM base. > > Understood. It is, nonetheless, additional mechanism, where the desired > functional control can be achieved by using what is already available. > > Additional mechanism is expensive. And it incurs the challenge of getting > everyone to adopt it. Using what is already available only requires > adoption by > those with the highest motivation. > > > > 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. > > The fact that some sender/signer situations might have some difficulty > coordinating doesn't justify adding an entire layer of mechanism that > needs to > be adopted by everyone. > > > > 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. > > Here's my suggestion: > > You should document the specific details for adoption and use by all > of > the affected actors, for each approach. One set of details for using a > selector-based mechanism and one set of details for using an ACL. Include > a > statement about who does and does not have to adopt it. Then compare the > degree > of effort and the motivation of the actors. > > > > 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. > > That puts it into a category like Unix "group" authorization > (self/group/other) > and that is driven by an underlying list of members. It's an ACL. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
