Further to my earlier message about clarifying the interoperability
problem, if the above statement is really the case, why not remove
i= entirely? We are already rather strongly warned about its use
in RFC 4871. So, what is its remaining value?
I wouldn't argue against that, since it seems likely that people will
misimplement i= no matter what we say, but the idea is that it's an
opaque identifier with two uses. One is as an audit key for the
signer; you get back complaints about mail you signed and you can use
it to help figure out what happened. The other is as a stream key for
the recipient; although the i= is opaque, it should be stable, and you
might want to treat all mail with the same i= in the same way.
As an end user, I'd like to know if the signing system says it's
signing the message on behalf of Aunt Tillie or Uncle George.
That's not a bad idea, but it's not DKIM, since DKIM makes no
assertions finer grained than "this domain signed this message".
Something tying the signature to an e-mail address would be a
reasonable extension for a future version. (I don't think ADSP does
this, since it, among other things, doesn't provide any way to say
that i= is an address without also requiring that it's the From: line
address.)
R's,
John
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html