Rolf E. Sonneveld wrote: > Hi, > > unfortunately I didn't have the time to do a full review of 4871bis, but > there's one thing I'd like to draw attention to. > In the original text of RFC4871 DKIM was described as: > >> DomainKeys Identified Mail (DKIM) defines a mechanism by which email >> messages can be cryptographically signed, permitting a signing domain >> to claim responsibility for the introduction of a message into the >> mail stream. > > In draft 2 of RFC4871bis DKIM is described as: > >> DomainKeys Identified Mail (DKIM) permits a person, role, or >> organization that owns the signing domain to claim some responsibility >> for a message by associating the domain with the message. > > I'm not very happy with the introduction of the word 'some' in front of > 'responsibility'. The way it is mentioned now is like one can say > 'somewhat dead' or 'a bit pregnant'. More or less undefined. And yes, > this 'some' can be determined by reading the entire doc and depends on > how DKIM is used, what fields are used for signing etc. But the words > 'some responsibility' will not sound very exact nor very attractive to > organizations who have to determine whether to invest in DKIM or not. > > So I suggest to either remove the word 'some' or describe in the same > paragraph what this 'some responsibility' exactly means. > > /rolf
Personally? I would go further to suggest to remove the usage of the term "responsibility" from the DKIM specification all together! Why? DKIM is no position today to provide any assurance to or for anyone to be indemnified from liabilities. With an unprotected raw Domain Signing protocol layer, all it does is give a potential plaintiff weight for a claim of "willful Negligence" when everything was done by the plaintiff to protect a domain (i.e. using ADSP) and a DKIM compliant receiver INTENTIONALLY ignored ADSP (on purpose) creating a situation where an end-user was HARM due to the receiver NEGLECT of a highly detectable malicious spoofed DKIM domain. I never like the usage of term "responsibility", especially when there was a lack of a focus to protect exclusive domain signed messages from abuse. I highly recommend that the term is removed from the specification. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
