Tim Gokcen wrote:
On Fri, 2007-05-04 at 14:17 -0700, Murray S. Kucherawy wrote:
On Fri, 4 May 2007, Tim Gokcen wrote:
> I notice that the new DKIM spec (draft-ietf-dkim-base-10) does not
> explicitly say which header field receiving agents are supposed to
> verify signatures against. Section 6.1 seems to imply that the "From"
> field can be verified, but neither confirms nor denies whether more
> hidden fields such as "Resent-From" (or "Resent-Sender") could be
used.
Section 6.1 says the "From" header must me signed, but that's the only
such assertion in the document.
The absence of guidance about what header fields to verify signatures
against is intended to make DKIM as flexible as possible. It will be a
very common case that the signing address matches the From header field,
and the verifier might treat that case specially. At least some of the
Sender Signing Policy drafts do consider such a signature to
automatically satisfy SSP. But DKIM can also be used to sign on behalf
of, for example, mailing lists, where the signing address corresponds
with [my opinion here] the List-ID header field.
DKIM is intentionally flexible enough for the verifier to make decisions
based on the type of signature present, and whether it corresponds with
the address on any particular message header fields. One thing to
consider, though, is that any agent that can sign a message can also add
any header fields they want, so it's probably more relevant who the
signer is than what their purported role is in handling the message.
I guess what I'm really trying to ask here is, does DKIM provide a
mechanism to tell the receiving MTA *which* field a particular DKIM
signature is intended to apply to? It's all right to say that MTAs can
check DKIM signatures against whichever fields they like, but I worry
that without either the ability for a signature to say, "match me
against field X" or an explicit minimum/recommended list of fields in
the spec that MTAs should be responsible for checking, that servers
implementing DKIM will only bother with, for example, From and Sender,
and possibly ignore fields that could have been validated, such as
Resent-From, or, to use your example, List-ID. Perhaps, whereas the
DomainKeys spec was too strict (match signing agent against Sender &
From *only*), DKIM is too permissive?
Tim,
If the i= or d= corresponds to an outer header that it also signed via h=,
you can at least have the assurance that the signing entity was willing
take responsibility for that assertion. That is a reasonable inference for
the receiver to make from that identity. Not explicitly stating that it
signs
for an outside header also neatly sidesteps the issue that it's not really
signing for the veracity of the local part per se.
Right now, we are using only the older DomainKeys spec, and in
particular this causes our messages to fail verification with Yahoo's
mail servers since the signing identity is in Resent-From (instead of
From or Sender) as we wish to mask the relay from the MUA. As I
understand it, the idea of DKIM & DomainKeys (and SPF & Sender-ID) is
not necessarily to validate that a message "from" joe(_at_)domain(_dot_)com is
*really* from that address, but to provide a mechanism whereby an MTA
at some point in the relay chain cryptographically asserts a certain
responsibility for the message. This increases the verifiability of
that relaying agent, and thus on the receiving side the MTA may decide
to trust the message more than it otherwise would, since if the
message turns out to be spam/phishing/etc. junk, then at least there
is some degree of accountability.
Is my reasoning correct?
DKIM-base does not have the concept of "failing" if it doesn't match an
outside header. The identity it asserts either validates or it doesn't. You
are correct about the part about asserting a certain responsibility though.
Which is actually the feature: you can use that identity irrespective of
whether it maps to an outside header to do things like reputation lookups,
etc. For doing the gold-star annotation like Y! does in their MUA, it is
really something that we wanted to enable, but not get sucked down the
rat hole of human factors questions. For that, it really depends a lot on
what information you're trying to convey to the user, and I'm sure that
we can all agree that there isn't a canonical answer to _that_ :-)
Mike, eventually we'd like to have a BCP that lays these
non-normative
considerations out though, I think
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev