-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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