> -----Original Message----- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Franck Martin > Sent: Wednesday, April 06, 2011 12:04 PM > To: Steve Atkins > Cc: DKIM WG > Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value) > > 1) How hard is it to add a new dkim header like st= considering the > current software implementation of DKIM
Fairly simple. I've opened a feature request for libopendkim to add it, and I expect it in the next release. I'll see if I can extend our stats stuff to cover use of unknown tags so we can track uptake. > 2) Can we use i= for a purpose of reputation as a) it's meaning is > loosely defined, b) it is there already (cf (1) ) c) it has been used > by some to differentiate different emails in the same domain. You could, if you know that the use of "i=" by a given SDID is consistent, and it's useful for you to track per-AUID reputation. Those are two big "if"s to me. > 3) Should we better get DKIM to sign a 5322 header because a) any DKIM > implementation can do it b) for senders it is easy to add a header when > the email is created and then sign it on the way out, than to figure > what type of email it is on the way out during signing. c) for > receivers a signed header is easy to process likewise. To summarize my current feelings on that question: Data about a message belongs in a header field; data about a signer belongs in the signature. > 4) Would senders and more important receivers likely to adopt such > mechanism to mimic IP reputation with dkim, rather than using > subdomains. Probably, if it can be shown to be effective. We need data to support widespread adoption. There are lots of people on this list that are spending a lot of energy speculating about what we need and what will work. How many of us are actually willing or able to conduct some experiments and report back data, and put energy into writing drafts, versus simply being visibly sad or upset about what's "missing"? -MSK _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
