>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
