On 4/30/11 10:37 PM, Murray S. Kucherawy wrote: > > -----Original Message----- From: Hector Santos > > [mailto:hsan...@isdg.net] Sent: Saturday, April 30, 2011 9:10 PM > > To: Murray S. Kucherawy Cc: ietf-dkim@mipassoc.org Subject: Re: > > [ietf-dkim] Output summary - proposing ODID "Originating Domain > > Identity" > > > > 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.
I think this missed Hector's concern. Perhaps it would have been clearer indicating confusion was in respect to "i=" parameter now called the AUID which can be a copy of an address that was within the From header field. The domain can differ whenever the AUID is a subdomain of the ODID when allowed by the key rr. Section 3.5 had stated the following omitted information: INFORMATIVE DISCUSSION: This document does not require the value of the "i=" tag to match the identity in any message header fields. This is considered to be a verifier policy issue. Constraints between the value of the "i=" tag and other identities in other header fields seek to apply basic authentication into the semantics of trust associated with a role such as content author. Trust is a broad and complex topic and trust mechanisms are subject to highly creative attacks. The real-world efficacy of any but the most basic bindings between the "i=" value and other identities is not well established, nor is its vulnerability to subversion by an attacker. Hence reliance on the use of these options should be strictly limited. In particular, it is not at all clear to what extent a typical end-user recipient can rely on any assurances that might be made by successful use of the "i=" options. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html