Thanks Dave, Let's give it a day or two more to see if anyone else has suggested changes then Barry & I will think about folding in your suggestions.
Cheers, S. Dave CROCKER wrote: > > Barry Leiba wrote: >> Description of Working Group: >> >> The Internet mail protocols and infrastructure allow mail sent >> from one domain to purport to be from another. While there are >> sometimes legitimate reasons for doing this, it has become a >> source of general confusion, as well as a mechanism for fraud and >> for distribution of spam (when done illegitimately, it's called >> "spoofing"). The DKIM working group has produced standards-track >> specifications that allow a domain to take responsibility, using >> digital signatures, for having taken part in the transmission of >> an email message and to publish "policy" information about how it >> applies those signatures. Taken together, these will assist >> receiving domains in detecting (or ruling out) certain forms of >> spoofing as it pertains to the signing domain. > > I suggest replacing the last sentence with something more generic, to avoid > the > debate about how much any of this pertains to spoofing, per se. Perhaps > instead > have a value proposition statement derived from the one in the Overview > abstract: > > These mechanisms permit email receivers to make additional assessments > about > messages. > > >> 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 assisting receiving domains in detecting some >> spoofing of known domains. The standards-track specifications do >> not mandate any particular action by the receiving domain when a >> signature fails to validate. That said, with the understanding >> that guidance is necessary for implementers, the DKIM documents >> discuss a reasonable set of possible actions and strategies, and >> analyze their likely effects on attacks and on normal email >> delivery. > > Delete the first sentence, per my concern above. At the least, the sentence > appears to be largely redundant with the preceding paragraph's last sentence. > > Isn't the second sentence incorrect? Doesn't DKIM mandate treated a failed > validation the same as no signature present? > >> The previously chartered deliverables for the DKIM working group >> have been completed: >> >> * An informational RFC presenting a detailed threat analysis of, >> and security requirements for, DKIM. (RFC 4686) >> >> * A standards-track specification for DKIM signature and >> verification. (RFC 4871, updated by RFC 5672) >> >> * A standards-track specification for DKIM policy handling. >> (RFC 5617) >> >> * An informational RFC providing an overview of DKIM and how it >> can fit into overall messaging systems, how it relates to other >> IETF message signature technologies, implementation and >> migration considerations, and outlining potential DKIM >> applications and future extensions. (RFC 5585 and >> draft-ietf-dkim-deployment, in its final stages) >> >> (One previously chartered deliverable, a standards-track >> specification for DKIM DNS Resource Record(s), was dropped by >> agreement between the working group and the Area Directors.) > > Do re-charters usually contain all this history? > > >> The working group is now ready to switch its focus to refining and >> advancing the DKIM protocols. The current deliverables for the >> DKIM working group are these: >> >> * Advance the base DKIM protocol (RFC 4871) to Draft Standard. >> >> * Collect data on the deployment and interoperability of the >> Author Domain Signing Practices protocol (RFC 5617), and >> determine if/when it's ready to advance on the standards track. >> Update it at Proposed Standard or advance it to Draft Standard, >> as appropriate. >> >> As before, several related topics remain out of scope for the DKIM >> working group. These topics include: >> >> * Reputation and accreditation systems. While we expect these to >> add value to what is defined by the DKIM working group, their >> development will be separate, and is out of scope for the DKIM >> working group. >> >> * Message content encryption. >> >> * Additional key management protocols or infrastructure. >> >> * Signatures that are intended to make long-term assertions beyond >> the expected transit time of a message from originator to >> recipient, which is normally only a matter of a few days at >> most. >> >> * Signatures that attempt to make strong assertions about the >> identity of the message author, and details of user-level >> signing of messages (as distinguished from domain-level keys >> that are restricted to specific users). >> >> * Duplication of prior work in signed email, including S/MIME and >> OpenPGP. > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
