dkim-dev
[Top] [All Lists]

Re: [dkim-dev] DomainKeys vs DKIM: Identifying the Sending Domain

2007-05-05 13:43:52
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?

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?

--
Tim Gokcen
Mpathix - Development.
_______________________________________________
dkim-dev mailing list
dkim-dev(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-dev