John Levine:
> 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 before we have real-world experience.
Wietse
> 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
