On Feb 18, 2009, at 3:11 PM, John Levine wrote: >> Disagree. One such use case is noted in the draft, where an domain >> has a premium service and a free service, and tags signatures >> accordingly so that users of the premium service avail themselves >> of the better reputation that service might have. > > Right, but that has nothing to do with i=. They'll use something > like d=foo.example and d=premium.foo.example. The reason they do > that is because that's the way to ensure that receivers will see > them as two streams.
While segregating reputations through the use of signing sub-domains to that of an email-domain might be how DKIM could be used, it would be establishing a dangerous precedent to also consider this to be a means to meet the goals established by the DKIM charter of preventing domain spoofing. This would suggest sub-domains are authoritative for parent domains. :^( >> Suggestion: leave i= opaque, and let's see what operators (on both >> ends of the transaction) do with it. >> >> But i= isn't opaque, not as a whole anyway. It has the syntax of >> an email address, and the domain part of that address MUST be the >> same as or a subdomain of the d= value. > > I fear you may misunderstand what opaque means. There are similar > syntactic constraints on message ID's, but they're just as opaque. > A receiver can verify that the field meets the mechanical rules, but > that doesn't tell you anything useful about the field's semantics, > it just tells you whether the sender has broken software. Perhaps a better way to state what is meant when there is no direct association between that of the signing domain (d= value), or that of the "on-behalf-of" identity (i= value) would be to describe these values as either "Associated" or "Unassociated". When the d= value can not be associated with an email-address domain (where even parent domains would also be excluded), it would represent a third-party signature. When the i= value can not be associated with that of an email-address, there should be no expectations that it references a valid destination. It seems both inaccurate and counter productive to describe the d= value as ever being opaque, and it seems safe to do so for the i= value only when not associated with other email-addresses within the message. Please do not overlook the intended goal established for DKIM so soon. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
