On Sun, 2005-08-14 at 22:30 -0700, Dave Crocker wrote: > On Sun, 14 Aug 2005 16:42:01 -0700, Jon Callas wrote: > > > 1. DKIM makes it easier to detect sender forgery. The three important > > > kinds of forgery are: > > > > > I think I'm in violent agreement with you. I'd state it slightly > > differently. > > I'm suggesting some minor changes, only to tighten it up a bit: > > > There is nothing in an ordinary email message, except for the RCPT TO > line > and the IP address of the host that sent it to you, that is a reliable > identifier.
RCPT TO is not a reliable identifier, nor one that would really establish any trust of the message. Often the RCPT TO identifier is invalid to induce a message bounce. I guess this statement would be assuming the message was delivered to a local mailbox, but so what? > A validated DKIM signature lets you take some reasonable subset > of the message you received and know that it came from a designated source. There is nothing requiring a signature be bound to any sub-set of the message. In addition, there is no existing convention for communicating such binding reliably to the recipient. Statements that use the terms "you" or "sender" should attempt to clarify who is playing the role of "you" or "sender". > The main benefit of DKIM is that a validating agent can know where the > message came from. The signature does not indicate the actual source of the message. In fact, the signature is independent of the immediate source of the message and this creates risk should the signature be used as a basis for acceptance under such a false impression. How about: ,--- | The assured benefit of DKIM's verified signature is authentication of | the domain accountable for permitting the initial introduction of the | message. DKIM does not indicate who within the domain is accountable | for the message. DKIM only indicates an accountable domain best able | to respond to reports of abuse. | | Optional assertions may attempt to constrain headers within the | message to be related to the signing domain. Such relationship will | not encompass the local-part of a mailbox-address and is out of scope | for DKIM. Even policy assertions regarding a domain can not be | reliably communicated to the recipient, which precludes any claims | or justification that depends upon such communication. '--- > This is more reliability than email source identification has ever > had before. Reliability would be a poor way to describe a fragile signature scheme. How about: ,--- | DKIM provides a means to authenticate the initial source of a message | with a name, as opposed to the immediate source of a message with an | IP address. This differences helps eliminate much of the collateral | damage that may occur when limited to using only the IP address of the | immediate source as a basis for acceptance. '--- Take some of the weaker and more contentious items off of the table. DKIM is not about preventing forgery. Such a statement confuses assurances of the message's author with that of the domain granting initial access. The concept of the author should be left to S/MIME and OpenPGP. The goal of wide deployment necessitates a narrower scope. Don't let DKIM become a house of cards built upon a set of assumptions that 'could' be true, when you tilt your head. By limiting DKIM to only providing an accountable domain and saying nothing about what may or may not be true about anything else in the message, this still be worthy of of merit. Consider the assertions which may attempt to add constraints to headers secondary at best. -Doug _______________________________________________ ietf-dkim mailing list <http://dkim.org>
