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