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:dhc(_at_)dcrocker(_dot_)net]
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