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

[Tim Gokcen]

> 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.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.