> -----Original Message-----
> From: Douglas Otis [mailto:do...@mail-abuse.org]
> Sent: Wednesday, March 11, 2009 7:40 PM
> To: MH Michael Hammer (5304)
> Cc: dcroc...@bbiw.net; ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingthe
> errataafter the consensus call
>
>
> On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote:
> >> On Mar 11, 2009 11:12 AM, Douglas Otis wrote:
> >>
> >> The only logic for requiring either a DKIM signature that lacks an
> >> i= value, or one that matches against the From header, would be
> >> there is something special about a DKIM signature that lacks the i=
> >> value. There does not appear to be any rational semantics to
> >> explain what is implied when the i= value is missing. On that
> >> point, Dave is correct.
> >
> > You are incorrect Doug. Look at RFC4871:
> >
> > If the DKIM-Signature header field does not contain the "i=" tag,
> > the verifier MUST behave as though the value of that tag were "@d",
> > where "d" is the value from the "d=" tag.
>
> A signature lacking an i= value defaults to the d= value, but this
> does not represent a From email-address! As someone said, domains do
> not write emails, which leaves the "on-behalf-of" identity
*undefined*.
>
Whether i= or d=, when I go to look for the ADSP record I'm only looking
at the RHS of the address. Therefore, what does it matter if a signature
lacking an i= defaults to d=? Logically, unless I have a constraining g
value and even then (note well):
g= Granularity of the key (plain-text; OPTIONAL, default is "*").
This value MUST match the Local-part of the "i=" tag of the DKIM-
Signature header field (or its default value of the empty string
if "i=" is not specified), with a single, optional "*" character
matching a sequence of zero or more arbitrary characters
("wildcarding"). An email with a signing address that does not
match the value of this tag constitutes a failed verification.
The intent of this tag is to constrain which signing address can
legitimately use this selector, for example, when delegating a
key to a third party that should only be used for special
purposes. Wildcarding allows matching for addresses such as
"user+*" or "*-offer". An empty "g=" value never matches any
addresses.
Domains sign mail. Unless you can show that every user has access to
creating/modifying the keys in DNS. You have provided nothing that shows
there is an issue.
> > There is nothing special about a DKIM signature missing an i= filed.
> > One simply uses the d= field. Seems pretty straight forward to me.
>
> Why must an i= value only represent a From email-addresses when
> present, when it is equally okay for the i= value to be omitted? When
> a DKIM public key imposes a g= restriction, the i= value MUST contain
> the restricted local-part or the DKIM signature WILL NOT be valid.
So what's the problem? Do you expect domains publishing an ADSP policy
to intentionally not provide an i= value and include a g= value? I admit
that there will always be some people who will screw things up
regardless of how careful a framework is constructed and how many
warnings and cautions are provided...... so what? It's kind of like
publishing an SPF record that consists of only "-all" and then
complaining that people are not accepting your mail.
> It will be evident to an MUA whenever a restricted local-part does not
> match against a From header. It should also be safe for an MUA to
> annotate signed headers that match against the i= value, but not those
> that do not match, such as when the i= value is omitted or it omits
> everything but the d= value. In such cases, just the domain might be
> annotated.
>
And where is the problem? Go do the lookup against the d= domain. That
is what the default is. Notwithstanding the g tag constraint, this works
fine thank you very much.
> In either case, the i= value (on-behalf-of identity) might become
> declared as being opaque and thus defined as not representing a
> specific email-address. When the i= value is declared opaque, no
> email-address should be annotated, even when it happens to match
> against the i= value.
>
Conflating layers. Just because DKIM base considers it an opaque value
does not mean that ADSP must consider it an opaque value. By choosing to
publish an ADSP record one is at least indicating that a receiver (again
excepting the g tag case you specified with no i= present - a quite
artificial construct that should fail) should look at the RHS of the
string called an RFC2822From email address.
> >> Since the ADSP draft is already internally in conflict on this
> >> point, a simple solution would be to drop the i= value requirement
> >> in ADSP.
> >
> > I see no conflict.
>
> Oops. This has been corrected off-list since version 6. Section 3.2
> now states Author Signature. Well, Section 3.2 will need to change
> back to Author Domain if or when i= value dependence is removed.
>
> By removing the i= dependency from ADSP, the assertions of "all" or
> "discardable" could then apply to any DKIM signature by the domain.
>
As I have written multiple times (and I'm getting tired of repeating),
while simply using d= works fine for me, using i= can make deployment
easier for quite a few domains without any significant downside other
than causing some people to get ruffled feathers that DKIM base
considers the i= string opaque for it's purposes and ADSP imposes a
constraint (for those domains which choose to publish ADSP records) with
regard to checking against the RFC2822From email address (RHS).
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
