ietf-mxcomp
[Top] [All Lists]

Re: Using DK/IIM [was: Re: So here it is one year later...]

2005-02-01 17:35:18

This is almost entirely about message signing, so I'm going to at least copy ietf-mailsig, and we should probably move this thread off ietf-mxcomp.

Hector Santos wrote:

Jim, these are legit questions:

1) Who is the signer?  MUA or MSA?
MUA, MSA, or some other MTA along the way.

2) How should a MDA handle the following:
What the recipient does with the results of message signing are really up to him/her, but here is what I would probably do:

2a) A domain with DK/IIM published information but a non-DK/IIM payload?
If by "published information" you mean that the domain has published a policy that it signs all messages, then an unsigned message should at the very least be considered very suspect. I would probably just put it in the "spam folder".

2b) A non-DK/IIM domain?
Do what you do today.

2c) Broken DK/IIM message?
Same as an unsigned message. It will be trivial for attackers to create "broken" messages, so a broken signature is really not an indication of anything.

3) What is the role of the intermediatary router MTA?
If it's just providing a message routing function, it does not need to be signature-aware. If it is manipulating the message, it may need to verify and re-sign the message.

4) What is the relationship of the transport parameters; IP, HELO, MAILFROM
and RCPTO with a DK/IIM ready payload?  What upfront logic can be used?
No relationship. DK/IIM deal only with the payload, and not SMTP itself (unlike the first revision of IIM which used MAILFROM).

5) Since a MDA requires to view the PAYLOAD to validate the DK/IIM, what is
the policy for POST-SMTP failed DK/IIM results?
The policy I use is to color code the messages in my MUA using a filter that looks at the authentication results header.

6) Finally, how should gateway transformation systems handle DK/IIM payloads
which may get stripped.  For example, a console based mail system only needs
two parts:

The main headers:

    From:
    To:
    Subject:
    Date:

and the body:

    text body
It could do any number of things, like modify the subject line (much as I hate this) or put a warning line at the beginning of the body.

6a) How does this change the mail reader, online and offline?  For example,
should the presentation software display some "Red Warning Icon" suggesting
"Possible Invalid Message?"
That would be nice, when we can get it. For now, I'm happy with coloring the summary line in my MUA, but I suspect that MUAs will come along that can do much more.

-Jim