On Jun 20, 2013, at 11:28 AM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
It has many potential uses, but within DKIM itself, it's an expansion
Keep in mind that there are IANA registries for the tag names in both
the signatures and the key records. If you want to try something new,
just pick a tag name or two and have at it. RFCs 6541 and 6651 have
recently added signature tags.
I would think that i= would be a poor tag to use since a lot of people
already have opinions about what it means or doesn't mean.
Dear John and Jon,
Jon and John are right, in that web providers often track users using synthetic
subdomains or some type of cookie (which may offends users), and that the 'i='
tag has already been defined and constrained by things like ADSP. There is
extensive revenue generated aggregating and trading in the correlation of user
information after all. There is also a basic reality large providers are not
likely to review logs based on timestamps to determine which of their users
caused a particular complaint. Overcoming that reluctance was the motivation
in creating either a static or transitive opaque originator tag contained
within the DKIM signature as expressed in an I-D created back in 2005 that
listed various option concepts.
There are currently ongoing problems caused by compromised email accounts.
Some of the other concepts may offer ideas for various remedies when needs
arise. While the i= parameter has morphed to partially provide this role, it
also conflicts with intended uses defined by RFC5617 (ADSP). Too bad. The
idea of the signing domain offering an evolving opaque identifier designated
specifically for this purpose has merit. Perhaps it could use a newly defined
'o=' tag. Unfortunately, this may offend those who want to feel their emails
are anonymous and yet signed using DKIM.
The best that can be hoped would be to officially deprecate ADSP as it is being
supplanted by DMARC with a lower failure rate, and then offer a BCP for use of
NOTE WELL: This list operates according to