[ietf-dkim] Re: Role of Sender header as signing domain
dotis at mail-abuse.org
Thu Nov 30 14:27:04 PST 2006
On Nov 30, 2006, at 2:55 AM, Charles Lindsey wrote:
> There are two cases:
> 1. The MUA has been specially adapted to work with DKIM
> 2. The MUA has not been specially adapted
> We are supposed to be designing a system which will work with
> existing MUAs (i.e. case 2), so in that case the verifier's policy
> module can only communicate with the user via the body of the
> message - rather like those irksome systems which add long
> paragraphs to the end of messages to inform you of all the viruses
> they did or didn't detect.
> So in that case it is up to the policy module to describe its
> suspicions in a manner the user can understand whether he can see
> all the relevant headers or not.
> So it might say
> "This message was sent by joe at bar.com (good signature by
> bar.com) but you
> should notice that the From: address made no mention of bar.com."
> "This message was sent by joe at bar.com apparently on behalf of
> joe at foo.com,
> but there is no valid signature from either of them."
It should be understood modifying the body prevents a recipient from
using DKIM. Assuming the MUA does not directly support DKIM will
allow bad actors to make similar assertions within the body of the
message. Adding information to the body of the message must contend
with complex structures within HTML such as color and text schemes.
This too can be irksome while also damaging efforts of adopting a
truly secure strategy. At this _very_ moment, the recipient might be
able to validate DKIM messages based upon a trusted list, where an
assumption that the recipient can not MUST be done on an
> OTOH, if one can assume an adapted MUA as in case 1, then
> presumably the communication could be by some other channel
> (possibly using the headers), but such an MUA would, in any case,
> display all headers relevant for understanding the report from the
> policy module, including the Sender if appropriate.
In the case of Iconix for example, a company's logo may also be
displayed, perhaps this could be the seal of the Internet Banking
Federation. : )
Why would you consider it to be difficult for the MUA to check signed
headers against email-addresses found in the Address-Book or a
trusted list? The next step in this checking process would be to
discover whether the Signing-Domain is associated with the email-
address in question. Only when an association is established between
a trusted list and the email-address, and between the Signing-Domain
and the email-address, should the DKIM signature even be validated.
Not checking in this order conveys which messages pass anti-spam
measures, and unnecessarily burdens the receiving MTA. Having the
MUA selectively perform this function better ensures DKIM will not
burden the system (or increase costs), while dramatically improving a
recipient's ability to trust specific messages.
More information about the ietf-dkim