On Jan 21, 2010, at 7:25 PM, John Levine wrote: > YES to 1, 7, 8. NO to everything else. > > (I.e., do find out what people are doing, do not invent new unlikely > to be used mechanisms. Not opposed to 9, but seems contingent on 7 > and 8 happening first.) >
+1. No new features without some real world experience and a non-theoretical, non-niche requirement. Cheers, Steve > R's, > John > > > >> The list, as I've been able to distill it out of the lengthy discussions: >> >> 1. Advance DKIM base to Draft Standard >> >> 2. 3rd-party authorization label: >> https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-label/ >> If you have not read this draft, please do; we'd like to get a good >> sense of whether to work on this. >> >> 3. Other 3rd-party signing issues (New protocol? Info doc?) >> >> 4. Mailing list cohabitation ("dkim=except-mlist") >> >> 5. Other mailing list issues (info doc) >> >> 6. Specifying ADSP/forwarder guidelines for re-signing (is this >> different from mailing list issues?) >> >> 7. Collect data on deployment and effectiveness of DKIM base >> >> 8. Collect data on deployment and effectiveness of ADSP, and consider >> future of ADSP >> >> 9. Update overview and deployment/operations documents (info), as new >> data are collected. >> >> 10. Go dormant for a while, and revisit these questions in 8 to 12 months. > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
