RE: [Asrg] C/R Framework

"Eric Dean" <eric@purespeed.com> Thu, 15 May 2003 13:34 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 JAA08479 for <asrg-archive@odin.ietf.org>; Thu, 15 May 2003 09:34:03 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4FD14p31049 for asrg-archive@odin.ietf.org; Thu, 15 May 2003 09:01:04 -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 h4FD13B31046 for <asrg-web-archive@optimus.ietf.org>; Thu, 15 May 2003 09:01:04 -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 JAA08471; Thu, 15 May 2003 09:33:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GItK-0007IQ-00; Thu, 15 May 2003 09:35:26 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GItK-0007IM-00; Thu, 15 May 2003 09:35:26 -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 h4FCsXB30708; Thu, 15 May 2003 08:54:33 -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 h4FCrSB30642 for <asrg@optimus.ietf.org>; Thu, 15 May 2003 08:53:28 -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 JAA08350 for <asrg@ietf.org>; Thu, 15 May 2003 09:25:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GIlz-0007G6-00 for asrg@ietf.org; Thu, 15 May 2003 09:27:51 -0400
Received: from ns2.tidalwave.net ([66.77.68.8] helo=mailgate.purespeed.com) by ietf-mx with esmtp (Exim 4.12) id 19GIly-0007Fi-00 for asrg@ietf.org; Thu, 15 May 2003 09:27:50 -0400
Received: from purespeed.com (mail.purespeed.com [66.77.69.8]) by mailgate.purespeed.com (Postfix Relay Hub) with ESMTP id 85EC813D2C; Thu, 15 May 2003 09:31:00 -0400 (EDT)
Received: from HOMEY [68.100.19.195] by purespeed.com (SMTPD32-7.13) id A5F9B7C200B8; Thu, 15 May 2003 09:28:25 -0400
From: Eric Dean <eric@purespeed.com>
To: Jon Kyme <jrk@merseymail.com>
Cc: ASRG <asrg@ietf.org>
Subject: RE: [Asrg] C/R Framework
Message-ID: <MBEKIIAKLDHKMLNFJODBAEAGFDAA.eric@purespeed.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <E19GFWa-0006OG-00@argon.connect.org.uk>
Content-Transfer-Encoding: 7bit
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: Thu, 15 May 2003 09:30:42 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit



> Well, that's just a red rag to *some* bulls :-)
>
> I don't think that asserting that the same concerns apply to *other*
> systems
> adequately addresses concerns applying to *these* systems. Plus
> also - it's
> not strictly true, since the *necessarily* long life of this data in a C/R
> system has implications.


Yeah..that was just a placheolder...however, my thinking is that we should
be addressing the protocol..not how some systems implement persistent data.
For example, some systems may not use C/R to build whitelists.  Some may
just challenge very message..it would be stupid..but they could.  Within
client email software,, the C/R mechansim would have much less privacy
concerns.  So, I'm trying to divorce myself from implementations but rather
focus on seucrity implications of the protocol itself...could be wrong about
that..but that was my thinking.


> Another thing, may be I misread the text, but I can't see how (if
> multiple)
>  X-CM-Recipient / X-CM-URI header pairs are kept together.

They would be subsequent line items within the header file.

> Do you really need two headers? couldn't all this data be
> parameters in one
> header? Or have I really missed the point?

You have a point.  They very well could be a single line.  The thing to
consider is a case whereby I send a message to 20 recipients in a company.
Each one of those recipients will challenge me with a unique authenticator.
So, the recipients should be listed individually...whether we can use a
delimeter with the authenticator following..might be a better method.

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