Barry Leiba:
> After some discussion with IESG/IAB folks, I have an update to the
> proposed DKIM charter that I want to float here. The change is to the
> third paragraph, and relates to our not defining actions taken by the
> verifier when verification fails. The thought was, and I agree, that
> while it's true that we want (need) to leave this up to implementers
> and sys admins, it's not a good idea to have people just make it up,
> without
> some guidance and analysis. So here's my proposed replacement for the
> third paragraph in the proposed charter:
>
> ------------------------------------------------
> While the techniques specified by the DKIM working group will not
> prevent fraud or spam, they will provide a tool for defense against
> them by allowing receiving domains to detect spoofing of known domains.
> The standards-track specifications will not mandate any particular
> action by the receiving domain when spoofing is detected. That said,
> with the understanding that guidance is necessary for implementers, the
> threat summary should document a reasonable set of possible actions and
> strategies, and analyze their likely effects on attacks and on normal
> email delivery. The DKIM working group will not attempt to establish
> requirements for trust relationships between domains or to specify
> reputation or accreditation systems.
> ------------------------------------------------
>
> Comments ASAP, please.
I'm in favor. This focuses the effort on the first-order issue.
Too much discussion here is about the second-order details.
Wietse
_______________________________________________
ietf-dkim mailing list
http://dkim.org
