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.
1) DKIM can fail to validate. Whether it can "detect spoofing" is less clear.
I think the language should deal with the former, not the latter.
So:
"will not mandate any particular action by the receiving
domain when spoofing is detected"
->
will not mandate any particular action by the receiving domain
when a signature fails to validate.
2) We are putting a lot into the "threat summary", certainly far more than
is implied by its name. It seems pretty unlikely that an implementor is
going to be reading an IETF "threats analysis" document, for implementation
guidance. It equally seems odd to have a charter dictate where something
will be documented, since that decision is often a matter of working group
evaluation as things progress.
Mostly, the proposed language appears to be confused with an Implementor's
Guide. Sounds like the push-back you have received is to require a
(separate) Implementors Guide. These are always delightful to produce and
sometimes even useful.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org