Subject: RE: [Asrg] C/R Interworking Framework

From: "Eric Dean" <[email-masked]>
Date: Tue, 27 May 2003 10:16:40 -0400

>  >This document identifies MIME experimental content-type values for
> allowing automated C/R system interworking.
>  >[..]
>
> Aren't we using headers?

Headers seems to be an ambiguous term to me..maybe it's much clearer to
others.  I am not proposing the modification of SMTP to introduce new
headers.  The use of experimental MIME content values is just fine and
ensures comptibility with non-CRI systems as the are simply ignored..or
removed in some cases.

>
> Is there room in the specifications for the following:

There's room for anything that makes sense..and I like the term
specification better than proposed standard or draft since we are a research
group.

> 1. Tag or certification systems which will send their seal or certificate
> as a response.

So..if there is a third party CA...then we could validate the server.  Then
there are more headers introduced here..and it sounds as if you are moving
towards authenticated mail servers.  Not a bad idea..but don't believe it
has a place within CRI.  That's not to say that they couldn't be compatible
or run as ships in the night as an overlay security model..but don't think
they have a home in something as limited as CRI. I would recommend that you
write up your own thoughts on such a model using certificates.

> 2. Economic systems which will use the cryptographics or some
> other methods
> like hashcash to add costs to email.

Again, I see no conflict..but anyone can use any experimental MIME values. I
would also recommend that you write up your ideas here.

>
> What will stop a spammer from putting X-CM headers into the message

Well a spammer would have to engage in a 3-way handshake process using valid
domains, MX records, and sender address.  While some will in fact commit
such crimes, others may be detered.  Placing the headers in a message merely
allows a CRI system to respond.  It doesn't create an additional
vulnerabilities.

> and
> what happens in that case - is there message let through or the
> C/R system
> responds to it, thus validating the receiver's email?

CRI only automates what user's automatically do today.  A mail system would
have to maintain state of all outgoing email and then automatically respond
to CRI messages.  Sending unsolicitied CRI messages would have the same
effect of sendig an unsolicited TCP socket to a stateful firewall.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 27 May 2003 22:19:59 -0400

>ensures comptibility with non-CRI systems as the are simply ignored..or

I meant mail headers as defined in RFCs 822 and 2822. A MIME header I 
believe can be used anywhere inside the message body in any part of the 
message if the message if multi-formed. RFC 822 headers are only used on 
the entire message body.

>write up your own thoughts on such a model using certificates.

Perhaps we should leave enough room or provide some form of an extension 
mechanism where in implementations can provide their own ways for 
validating the responses while leaving the basic CRI protocol intact. This 
would allow all C/R systems to interoperate and leave room for people to 
piggy-back various systems on top of the basic CRI protocol.

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 27 May 2003 22:19:59 -0400

---

From: "Eric Dean" <[email-masked]>
Date: Wed, 28 May 2003 09:48:02 -0400

> message if the message if multi-formed. RFC 822 headers are only used on

Hmm..yes, that would seem more appropriate.

> piggy-back various systems on top of the basic CRI protocol.

That's an excellent way to put it.  Whatever we do, we should not be in
conflict with other methods.