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

[Michael Thomas]

Tim Gokcen wrote:
>> Tim Gokcen wrote:
>>> 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?
>>
>> DKIM specifies which fields are part of the signature.  So I suppose 
>> the question is what you mean by "apply to".  From your earlier notes 
>> in this thread, you appear to focus on something akin to authorship.
>
> Well, in the case of our pull-push forwarding system, for example, 
> message headers might include:
>
> From: Joe at originalemail.com
> To: Phil at realrecipient.com
> Resent-From: pushpullforwarder at mpathix.com
> DKIM-Signature: h=From:To:Resent-From:<more>, d=mpathix.com, <etc.>
>
> with a signature whose h= value includes at least all three of those 
> header fields and whose d= value is mpathix.com. To oversimplify 
> things, my problem is how do I make sure that the receiving MTA will go:
>
> "mpathix.com signature that includes several fields..., oh, look, 
> Resent-From is from that domain. I'll do a DNS TXT lookup on the 
> selector (etc.) for mpathix.com and see if it matches this sigature...."
>
> Currently, with DomainKeys, Yahoo goes:
>
> "mpathix.com signature that includes several fields.... nope, neither 
> From nor Sender is from mpathix.com, I can't use this DK signature for 
> anything."
>
> What I'd like is some kind of assurance (or ability to specify) that a 
> receiving MTA will check the Resent-From field (or anything else) when 
> matching the d= parameter. Maybe that lays too much of an onus on the 
> receiving MTA, though. 

More to the point, that's really the receiving MTA's business about how it
wants to use the signature. But you can set the i= to the value in the 
Resent-From
which gives a pretty good hint that that's what you're trying to convey. 
But
fundamentally, the receiver may have no use for a signature that 
corresponds to
the Resent-From. But that's OK too... we're providing the mechanism here,
not the whole system.
> But I guess it's the distinction between "failed to validate because I 
> didn't find the d= value in any outer header" and "ignoring DKIM 
> header validation because I didn't find the d= value in any outer 
> header *that I care about*"
Bingo.

       Mike