ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain Identity"

2011-05-01 20:28:16
On 4/30/11 10:37 PM, Murray S. Kucherawy wrote:
-----Original Message----- From: Hector Santos
[mailto:hsantos(_at_)isdg(_dot_)net] Sent: Saturday, April 30, 2011 9:10 PM
To: Murray S. Kucherawy Cc: ietf-dkim(_at_)mipassoc(_dot_)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