Subject: Re: So here it is one year later...

From: Jim Fenton <[email-masked]>
Date: Tue, 01 Feb 2005 09:57:00 -0800

I think I'll stick with the "in layman terms" part of the message 
because that's most clearly stated:

Hector Santos wrote:

>In layman terms:
>
>What if my SMTP mail server detects a non-DK/IIM ready message?
>  
>
IMO, it will be a very long time (if ever) before a "typical" mail 
server will be able to take some action such as rejecting a message 
based on a missing signature, except possibly when the originating 
domain advertises that it signs all of its mail.

>You need to answer that question otherwise what is the use of using DK/IIM
>if a system still needs to work and be ready for non-DK/IIM messages?
>  
>
It's another message classification criterion, and when present enables 
reputation and accreditation based on who the signer is.

>Now of course, it might work well in an exclusive CISCO corporate/enterprise
>settings, a big pat on the back, an exciting marketing and promotion largely
>based on "hope"  I can imagine for your big customer base.  But this is not
>a standard across the board.
>  
>
I hope it's obvious that's not Cisco's intent.  But it should be 
possible with standards-based message authentication for anyone to more 
accurately whitelist their suppliers, customers, and partners, to make 
sure that their messages never get lost.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 1 Feb 2005 14:22:31 -0500

Jim, these are legit questions:

1) Who is the signer?  MUA or MSA?

2) How should a MDA handle the following:

2a) A domain with DK/IIM published information but a non-DK/IIM payload?
2b) A non-DK/IIM domain?
2c) Broken DK/IIM message?

3) What is the role of the intermediatary router MTA?

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?

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?

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

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?"

Thanks

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office

---

From: Jim Fenton <[email-masked]>
Date: Tue, 01 Feb 2005 16:35:08 -0800

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.

>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 

>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.

>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).

>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.

>which may get stripped.  For example, a console based mail system only needs
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.

>"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