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