On Jun 20, 2013, at 11:28 AM, John Levine <jo...@taugh.com> wrote: >>> It has many potential uses, but within DKIM itself, it's an expansion >>> socket. > > 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. http://tools.ietf.org/html/draft-otis-dkim-options-00 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 'i='. Regards, Douglas Otis
_______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
