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 [EMAIL PROTECTED] (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 [EMAIL PROTECTED] apparently on behalf of
[EMAIL PROTECTED],
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.
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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
