On Jun 16, 2008, at 1:13 AM, Murray S. Kucherawy wrote: > On Thu, 12 Jun 2008, [EMAIL PROTECTED] wrote: >> Adding to this, Murray Kucherawy's draft captures the i= (identity) >> parameter and a worthless s= (selector) parameter. The s= >> parameter offers little value since the d= (key domain) parameter >> is missing. Only the d= parameter (upon which the s= parameter >> rests) represents a domain validated by a verified signature. > > It's not worthless to an implementor or administrator interested in > figuring out why his/her mail isn't verifying properly.
And to resolve such issues, knowing which Key Domain is being used is still important, but nonetheless ignored. If fact, the key domain is likely needed to resolve issues for organizations that use sub-domains! > Any developer would love to have as much of the original data as > possible to reconstruct the failure scenario. Your strategy appears to ignore the _least_ easily changed identifier validated by a DKIM signature. Controlling resource costs for collecting and distributing defensive information _requires_ stable identifiers. Without some level of identity stability, any defensive strategy will _explode_ due to enviable abuse. No database scheme can scale to accommodate virtual identifiers that only exist within a message! > Not everything in this working group is about crypto and security. > We implementors do sometimes think about other things. While such a scheme might be seen as Sender friendly if adopted, this would doom DKIM. Selectors devoid of the publishing domain offers no value. To suggest otherwise would be in support of a false premise. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
