RE: [Asrg] C/R Interworking Framework

>  >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
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg