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
