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

[Douglas Otis]

On May 4, 2007, at 12:25 PM, Tim Gokcen wrote:

> Under the DomainKeys spec, I ran into some trouble with respect to  
> identifying the sending domain. The DomainKeys spec explicitly says  
> that  receiving agents must use the From: or Sender: field to  
> identify the sending domain against which to authenticate the  
> DomainKeys signature.
>
> Writing a push-pull mail-forwarding system, I found this  
> restriction aggravating with respect to ensuring end-user  
> experience. Ideally we want the human recipients to see only the  
> "original" From address and be unaware (unless they examine  
> extended header information) that the message was forwarded. Of  
> course different e-mail programs will behave differently, but most,  
> for example, do not show low-level fields such as "Received:", so  
> it should be possible.

Ideally, MUAs should limit annotation to email-addresses previously  
added to a recipient's address book which remembers associated  
signing domains.  Only those messages should then receive annotations  
indicating the DKIM source as having been verified.  Any other method  
expects the user to be able to visually recognize sources of all  
annotated messages, which is not realistic.

> However, we would also like to ensure that the receiving MTA is  
> able to verify our server using Domain Keys, SPF/Sender-ID, etc.,  
> in order to avoid the messages being identified as forged-return- 
> address spam.
>
> With SPF/Sender-ID, we can do this by populating the "Resent-From"  
> field with an address belonging to the forwarding domain. Hotmail  
> and other SPF/Sender-ID verifiers correctly find our SPF domain  
> records and validate the Resent-From.

There should _not_ be any reliance placed upon Sender-ID or SPF!  The  
local-part macro feature of the SPF record scripts, and the  
inordinate level of transactions that may be invoked when evaluating  
SPF records creates an _extremely_ dangerous hazard that increases as  
evaluation of these records become common place and extended to other  
email email-addresses or domains.

> With Domain Keys, we were forced to use the "Sender" field, but the  
> downside is that some e-mail programs (e.g., Outlook 2003) display  
> this field to users, displaying "From XXX sent on behalf of YYY"  
> where XXX is the Sender field and YYY is the From field.
>
> 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.

DKIM should not be forced to relate to _any_ header.  The MUA should  
be structured to recognize a prior email-address initially validated  
by the user using some out-of-band means.

> Is the selection of what to verify against truly absent from the  
> DKIM spec? Is there anything we can do in order to ensure that the  
> receiving mail server (verifier) is able to correlate the sending  
> domain with a DKIM entry and thus verify the message against our  
> published DNS TXT records, without resorting to highly-visible  
> fields such as "From" or "Sender"?

Some have advocated a policy record to restrict which fields can be  
associated with a DKIM signature.  Reliance on such a mechanism  
however will likely place users at greater risk, as non-compliant  
messages from similar domains will still mislead them.  When  
misleading messages receive any annotation based upon compliance with  
some type of policy record restriction, this would only serve to  
increase the success rate of phishing.

-Doug