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

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