On May 11, 2009, at 3:55 AM, Charles Lindsey wrote:
On Sat, 09 May 2009 21:08:33 +0100, Steve Atkins
<steve(_at_)wordtothewise(_dot_)com
wrote:
i: Additional information about the identity of the user or
agent for which this message was signed
This one is more controversial. It adds an awful lot of complexity
and confusion about the semantics of what a signature is and quite
a few people (myself included) would prefer it went away. But there
are some potential uses for it, and some are already invested in
it, so it seems unlikely we'd reach any consensus to drop it.
At the moment, this tag plays no part in the protocol (except that
it needs to be correctly signed). It has caused confusion, which our
recent errata have sought to dispel. Now there is the opportunity to
sit down and define some proper rules for its use, if we are so
minded (e.g. in mailing lists). Essentially, it could be useful for
signatures which are NOT by the Author Domain.
Disagree. This tag plays an important role in the protocol! This tag
permits differentiation of intra-domain sources to mitigate replay
abuse, and is supported by RFC 5451 to aid MUA annotations. Any
attempt to use the i= value for email-addresses where the signing
domain is not authoritative will create incompatibilities.
Different domains can authorize a DKIM signing domain within a single
transaction. A convention using a specific dedicated sub-domain, such
as "_authorized", within the i= value could even indicate an
expectation of the signing domain being authorized by the From email-
address domain. Perhaps this could be done with base-64 encoded hash
labels placed within the From email-address domain. This would be a
fairly low overhead (about that of CNAMES), and allow any number of
domains to be authorized.
For example:
<hash of example.com>._dkim_authorized.other-example-domain.com TXT
"example.com"
From: Jon(_dot_)Doe(_at_)other-example-domain(_dot_)com
DKIM-Signature: i=radius_12345(_at_)_authorized(_dot_)example(_dot_)com;
d=example.com
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html