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.
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.
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html