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