RE: [Asrg] C/R Interworking Framework

Yakov Shafranovich <research@solidmatrix.com> Wed, 28 May 2003 02:29 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15376 for <asrg-archive@odin.ietf.org>; Tue, 27 May 2003 22:29:03 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4S2Sda12092 for asrg-archive@odin.ietf.org; Tue, 27 May 2003 22:28:39 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S2SdB12089 for <asrg-web-archive@optimus.ietf.org>; Tue, 27 May 2003 22:28:39 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15367; Tue, 27 May 2003 22:28:32 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KqeZ-0004xv-00; Tue, 27 May 2003 22:26:59 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19KqeY-0004xs-00; Tue, 27 May 2003 22:26:58 -0400
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S2LPB11865; Tue, 27 May 2003 22:21:25 -0400
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h4S2KwB11824 for <asrg@optimus.ietf.org>; Tue, 27 May 2003 22:20:58 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14926 for <asrg@ietf.org>; Tue, 27 May 2003 22:20:52 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19KqX8-0004pe-00 for asrg@ietf.org; Tue, 27 May 2003 22:19:18 -0400
Received: from 000-232-115.area5.spcsdns.net ([68.27.145.214] helo=68.27.145.214) by ietf-mx with smtp (Exim 4.12) id 19KqX6-0004pY-00 for asrg@ietf.org; Tue, 27 May 2003 22:19:17 -0400
Message-Id: <5.2.0.9.2.20030527221043.00ba0b18@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Eric Dean <eric@purespeed.com>, asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: RE: [Asrg] C/R Interworking Framework
In-Reply-To: <MBEKIIAKLDHKMLNFJODBIEDFFFAA.eric@purespeed.com>
References: <5.2.0.9.2.20030525004309.00bc9e60@solidmatrix.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Tue, 27 May 2003 22:19:59 -0400

At 10:16 AM 5/27/2003 -0400, Eric Dean wrote:

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

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.

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

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 / <research@solidmatrix.com>
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)
---------------------------------------------------------------------------------------------------  

_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg