> 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.
> ------------------------------------------------
This basically seems OK to me. I do question whether the threat analysis
document (which I guess we're calling the threat summary now) is the right
place for this, however. And even if it ends up being the right place, do we
really want to mandate the eventual location in the charter?
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org
