On 4/6/11 3:06 PM, John Levine wrote: > > For there to be reasonable semantic meaning, it must be > > understandable. > > > > Whether it were done by adding semantic signposts for i=, > > additional tag values, or additional 5322 headers, it should *not* > > be done in an ad-hoc fashion. > > Quite right. We need drafts, implementations, all the usual stuff. > At this point, i= is clearly nothing other than an opaque token with > a funky syntax, which seems not to be very useful semantics.
John, i= is currently defined as "The Agent or User Identifier (AUID) on behalf of which the SDID is taking responsibility". Other than remaining within the signing domain, the token need not be recognizable to receivers, but according to current definitions, the signing domain asserts their recognition of this field as a token for the AUID. In that sense, the token could be considered opaque for receivers, but not without meaning or value from the aspect of tracking or dealing with abuse. When used as defined, it provides a means for the signing domain to differentiate their mail streams using a common signature. There are no similar semantics with From, Sender or any other header that can be found within a message. > I get the impression that some people (not you) are under the > misconception that if they can sneak their pet feature into the > spec, that will force everyone to implement it. Too Big to Block domains may have trouble dealing with compromised accounts where the i= field could prove useful. This is not about sneaking in some odd or until now undefined field. While all large domains include a way of identifying the AUID in some odd fashion, the i= field is where this token obtains a standardized location. As such, it can greatly aid in tracking and reporting abuse. We have yet to rely upon domain reputation, but the prospect of dealing with IPv6 is sure to have domain reputations playing a greater role. It does not appear anyone at this time has a good handle on controlling compromised accounts. I like having an ability to use different identities from the same account. If my mom's system were to become compromised, by having a way for abuse reporting to accurately source a problem, this improves the chance that affected user will be made aware of the problem, as they should. Adding a new header that replicates the signing domain would still not offer any assurance the signing domain was the agent that added this new header. The only place do do this properly would be within the DKIM header itself. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
