Murray S. Kucherawy wrote:
Hector stated:
I think this message by Barry in March 2009 summarizing a conference
call between Pasi, Stephen and Barry nicely captures the upper/lower
layers, ADSP, i= and outputs conflicts that continue today:
http://mipassoc.org/pipermail/ietf-dkim/2009q1/011314.html
I think that message doesn't say a single thing about layers.
It looks entirely procedural to me.
Darn it. I copied the wrong link and now I can't find it. :(
Let me search again...... Quick search failed. I'll search deeper
later if you still want me to. I will find it at some point just to
have it in my DKIM notes.
Barry provided an outline of the AUID, i=, ADSP relationships
including possible logic in how to work with it, how it conflicts or
justified with layer and concluded with suggestions on how to move
forward. I thought it captured the unsolved issues and conflicts we
are still dealing with today highlighted in this Output Summary
thread. It was reading like as an possible algorithm to resolve the
ADSP input value; AUID vs From Domain value applicable to signing
practice.
But what it did most of for me (yesterday) was highlight the confusion
with AUID with the lack of an official DKIM label for an Originating
Domain Identity. I guess I was moving forward the past year with
integrating DKIM into our mail products and I see now I was mistakenly
labeling the AUID as the FROM domain when its not officially defined
as the From domain.
DKIM-BASE has it "Agent or User" yet defines it as the "i=" value
which has a direct and specific format related to SDID. So what is an
Agent or User? I think we can agree a USER is the From: address.
N'est-ce pas?
So perhaps to help shut down this ambiguity we should add a DKIM
terminology to clearly separate it from AUID.
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From: address. This identity
MAY be considered as an output communicated to an advanced
Identity Assessor module.
INFORMATIVE IMPLEMENTATION NOTE:
The ODID and SDID are inputs for the optional
Checking Signing Practices component as described
in the DKIM Service Architecture [RFC5585]
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html