On August 9, 2005 at 16:23, Michael Thomas wrote: > That's all true, but that's not what Dave asserted: > > > This is precisely what DKIM does. It is the domain administrator who > > defines > > the DNS records used by DKIM and DKIM's granularity of the validated > ^^^^^^^^^^^ > > identity is a domain name. > ^^^^^^^^^^^ > There's finer granularity than the domain name. The i= defines > it, not to mention the g=. Which in terms of a problem statement, > etc, is misleading to say that it's a secondary goal; it's been > a primary goal all along for everybody that I can determine except
Note, the setting of tag values is under the _control_ of the domain owner/administrator, not the author/sender. As I have noted in past discussions, I think the scope of DKIM is not well-defined in the DKIM drafts, which can lead to confusion. (This is independent of the merits of DKIM and how it compares to competing proposals.) For example, in the Overview, the following is stated: DomainKeys Identified Mail (DKIM) defines a simple, low cost, and effective mechanism by which cryptographic signatures can be applied to email messages, to demonstrate that the sender of the message was authorized to use a given email address. First, sender is not well-defined here. If interpreted in the context of RFC-2822, one may consider it the Sender: field, and possibly From: when Sender: is not specified. In the context of RFC-2821, it would be the SMTP MAIL FROM address. Since "to use a given email address" is mentioned, this directly implies rfc2822.From since this is what everyone sees when they read mail. Now, the way DKIM is actually defined, at the cryptographic signing level, neither rfc2822.from nor rfc2822.sender play a role. I.e. There is no (required) cryptographic binding to the rfc2822.from or rfc2822.sender of the message. The only role they play is in SSP checks, which has been discussed in other threads (especially to make it more secure). This is the only time that the author/sender has some form of control over the DKIM process, especially in protecting their address from malicious domains. --ewh _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
