First, I would like to thank those who offered feedback, since this
input is extremely valuable. I owe them a beer at least.
This draft update can not be submitted until after the meeting, but for
those interested, it is available at:
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-05bis-a.html
http://www.sonic.net/~dougotis/id/draft-otis-dkim-tpa-label-05bis-a.txt
These updates addressed many of the non-technical issues that were noted
in feedback received. I still hope to add more examples.
An issue drawing some heat was related to whether transparent
authorizations will be facilitated. I have added the term "informal"
third-party services as a group that includes mailing-lists, which
better describes the rationale. Even when mailing-lists lack individual
message authentication, having a certain means, via added header
fields, to direct messages to specific folders discourages abuse and
exploitation.
Better ABNF descriptions were provided, with a complete description of
the label encoding process. It did not change, since it follows network
order and IETF bit order conventions. :^)
In addition to breaking out each alternative confirmation method, a
place holder was included for a method to deal with various types of
IPv6 exchanges without there being a suitable strategy for dealing with
this issue. Much of the IPv4 space is blocked-off based on reverse PTR
records or AS assertions indicating residential assignment. There is no
practical method for tracking reverse space in IPv6. Dealing with
tunnels and carrier grade network address translators also impairs
confirmation tactics normally used in the IPv4 address space. A small
effort to define a protocol employing DKIM keys to sign SMTP-AUTH
challenges could prove to be a workable means for confirming client domains.
This assumption has been partially fleshed out in the updated draft.
Another draft describing this approach, or perhaps use of TLS could be
started. Cert cost is unlikely much of an abuse deterrent, but I could
be wrong. Using DKIM keys to answer a SMTP-AUTH challenges will have
less of an impact on resources.
TLS encodes messages in the public exchange and is a current standard,
but there is no conventional basis yet to authenticate the client. It
also seems bad actors will be in a better position to handle increased
overhead, so perhaps less is more.
There is also the issue related to the best method for introducing new
ADSP dkim tag values. Should additional values be separated with white
space, or ";"? It did not seem clearly defined in the ADSP draft. It
might require some experimentation to discover what works best.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html