On Thu, 30 Nov 2006 22:27:04 -0000, Douglas Otis <dotis(_at_)mail-abuse(_dot_)org>
wrote:
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(_dot_)com (good signature by bar.com)
but you
should notice that the From: address made no mention of bar.com."
or
"This message was sent by joe(_at_)bar(_dot_)com apparently on behalf of
joe(_at_)foo(_dot_)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
above.
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
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html