On Jun 18, 2013, at 7:59 AM, Dave Crocker <dcrocker(_at_)bbiw(_dot_)net> wrote:
On 6/18/2013 7:18 AM, Tony Hansen wrote:
I always thought it would be a nice follow-on to DKIM to provide a way
for a site to specify how that site was using i=; that is, to provide
some clarity and comprehension for that value. For example, our
implementation placed the authenticated userid into i=. I know of one
site that appears to use a hash of the authenticated userid. John L says
his site uses "how the mail was injected (submit, webmail, whatever) and
who the user was if it knows". When there is a deterministic mechanism
used to create i=, and the mechanism is known, then it is possible for
additional logic to be added to the receiving side as well.
I'm sure Tony already knows this, but just to make sure it's part of the
thread:
Anyone can define a value-added protocol layer on top of DKIM. It
can define all sorts of additional semantics.
It needs a method of declaring its presence, such as an extra
header field or a special external query, but after that, it's free to
define anything it wants, including a public meaning for i=
One could, for example, imagine a layer that asserts that the domain in
the rfc5322.From field MUST match the domain in the DKIM d= field, or at
least have an "organizational domain" match (that is, match at the name
portion that was delegated by a registry.
Oh, wait. That's DMARC.
See? It's possible.
I found that too:
http://tools.ietf.org/html/draft-fenton-dkim-reputation-hint-00
No traction either...
I think, the lesson here is to not mix function in protocols. The
authentication piece should be separated from the policy piece and same for the
reputation. This makes better building blocks.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html