[ietf-dkim] Re: Role of Sender header as signing domain
chl at clerew.man.ac.uk
Fri Dec 1 07:12:45 PST 2006
On Thu, 30 Nov 2006 22:27:04 -0000, Douglas Otis <dotis at mail-abuse.org>
> 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 individualized basis.
Though if the start of the added portion is clearly delimited, then it is
not too hard to establish that the signature is still valid for everythng
However, what is become clear is that verifiers will have to be prepared
to treat things differently according to the ability of their users. Some
possible policies might be:
1. Drop/quarantine suspicious messages regardless.
2. Give the user sufficient information to make the decision himself, but
by a mechanism that will work with current MUAs.
3. For those users with specially adapted MUAs, communicate with them by
whatever protocol has been standardized for the purpose.
However, I understood that this group was primarily charged with producing
a system that would work within #1 or #2.
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Email: chl at clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
More information about the ietf-dkim