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