Murray S. Kucherawy wrote: >> -----Original Message----- >> 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. > > That's unfortunate, but it's also the first case I've heard > of someone mistaking the AUID for the From: field.
To be more precise, may erroneous labeling of AUID as the author or user DOMAIN in the From: address for ADSP purposes. Its been an ongoing debate with what AUID (i=) is. Just see the recent threads with Fenton's proposal to remove it and some suggested to keep with refinements like i= should be the From address. This is why Barry's message is important here (got to find it) because if I can correctly recall, he showed both CON and PRO logic on how/why an undefined i= can be assumed to be the From and and the From.domain for ADSP purposes. >> 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. > > We already have a name for that: "RFC5322.From". We don't need a > new name for something old. If we want to say From.Domain is an identity, fine by me. > I don't see any ambiguity here that needs fixing, unless there > are lots of people that want to come forward now and admit > they had the same misunderstanding you did. There is plenty of archive evidence old and new regarding i= (AUID) ambiguity, including whether it should be a USER identity as the definition ambiguously says "Agent or User." Who/What is an Agent? Undefined? Who is the User? I presume the RFC5322.From? No? -- 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
