On Jul 12, 2006, at 3:18 PM, Michael Thomas wrote:
I'm not sure that Dave Crocker and I are in full agreement, but
it's close enough
that it should make people worry. Even though I've been thinking
about SSP for
a long, long time (IIM had the same concepts), it's not entirely
clear to me that
we know what problems we're trying to solve or whether they're
worth solving.
As far as I can tell, there are only a couple that have some
obvious constituencies:
1) I sign everything, for some value of everything
2) I don't send email at all.
All of the others are rather debatable -- and have been often. What
would be good,
I think, is to actually have problem statement for each new need
for policy/practices
advertisement, who would use it, why they would use it etc. The
current draft, IMO,
has too much of a "if you build it they will come" flavor to it,
and most especially
with respect to the "third party" stuff which I don't sense there's
any real agreement
on what it mean, or what problem it actually solves. In fact, I'm
fairly certain as
current specified, the "-" solves nobody's problems.
The policy/name-path approach provides two advantages:
1) Reduce grey-list exceptions when the OA != signing domain.
2) Improve status of messages where OA != signing domain, but where a
signing domain is authorized by the OA domain.
A small enterprise could utilize a major provider's DKIM signing by
posting domains a domain list (similar to PTR RRs) they authorize for
signing their messages. A copy of the provider's public key still
requires administrative arrangements or delegations, which
complicates key management and increases the related expenses. In
addition to reducing the management of the keys, the path name would
offer a defensive strategy permitting selective delays be injected
when associations are not obvious, and where the source has not sent
sufficient legitimate traffic to become white-listed. A delay may be
vital for block-listing for replay abuse, for example. These name
path lists can be declared open/closed/shut to cover the "basic"
constituencies (large one-name domains) while also improving upon the
applicability of DKIM for smaller entities. This could be done with
a new type of PTR RR that has a 16 bit field for binary assertion
flags, and a host name field. Currently, two or three bits could
cover today's current states related to DKIM. Two bits of the policy
field might define the RRset to be open/closed/shut.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html