Re: [Asrg] C/R Interworking Framework

Art Pollard <pollarda@lextek.com> Mon, 09 June 2003 22:24 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 SAA23894 for <asrg-archive@odin.ietf.org>; Mon, 9 Jun 2003 18:24:06 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h59MNhL09861 for asrg-archive@odin.ietf.org; Mon, 9 Jun 2003 18:23:43 -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 h59MNhB09858 for <asrg-web-archive@optimus.ietf.org>; Mon, 9 Jun 2003 18:23:43 -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 SAA23875; Mon, 9 Jun 2003 18:23:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PV1E-0007SW-00; Mon, 09 Jun 2003 18:21:36 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19PV1E-0007ST-00; Mon, 09 Jun 2003 18:21:36 -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 h59MM6B09753; Mon, 9 Jun 2003 18:22:06 -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 h59MLHB09728 for <asrg@optimus.ietf.org>; Mon, 9 Jun 2003 18:21:17 -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 SAA23833 for <Asrg@ietf.org>; Mon, 9 Jun 2003 18:21:10 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19PUys-0007S2-00 for Asrg@ietf.org; Mon, 09 Jun 2003 18:19:10 -0400
Received: from sccrmhc13.attbi.com ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 19PUys-0007Rn-00 for Asrg@ietf.org; Mon, 09 Jun 2003 18:19:10 -0400
Received: from art.lextek.com (12-254-130-29.client.attbi.com[12.254.130.29](untrusted sender)) by attbi.com (sccrmhc13) with SMTP id <20030609222040016001l7m1e>; Mon, 9 Jun 2003 22:20:40 +0000
Message-Id: <5.1.0.14.2.20030609161229.03cf3558@mail.1s.com>
X-Sender: PollardA@mail.1s.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
To: Rob Cameron <cameron@cs.sfu.ca>, Asrg@ietf.org
From: Art Pollard <pollarda@lextek.com>
Subject: Re: [Asrg] C/R Interworking Framework
In-Reply-To: <200306091332.46085.cameron@cs.sfu.ca>
References: <DD198B5D07F04347B7266A3F35C42B0B0FD040@io.cybercom.local> <DD198B5D07F04347B7266A3F35C42B0B0FD040@io.cybercom.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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: Mon, 09 Jun 2003 16:21:19 -0600

>Beyond this, I also think that C/R systems should be required
>to provide full support for message-id, in-reply-to and references
>headers.  That is, the framework should state that challenges
>and responses must (not should) provide a unique message-id
>and must (not should) properly form in-reply-to and references
>headers from prior e-mails in the chain.    By implementing these
>RFC2822 recommendations, C/R systems will give each other
>valuable information to address both looping and spoofing
>concerns.

I agree that we should have a references: header (just like the one in 
NNTP).  This would be useful for threading mail conversation threads among 
other things.  I have often wondered why current clients don't maintain 
this header and utilize it when available.  It would be so useful.

I think as has been mentioned previously in regards to CR systems in 
general (and I don't remember if it was mentioned in the CRI case), that 
what should happen is that the messages should be digitally signed by the 
sender.  The CR system would filter based in the digital signature rather 
than the FROM address.  Thus it would be quite possible for people to have 
multiple clients with the same digital signature (one for each e-mail 
address say) and they would only have to undergo the CR once -- even if 
they switched ISPs.  Furthermore, it would virtually eliminate spoofing 
since even if someone were able to obtain a previous copy of someone's mail 
and a list of all their friends, they still would be unable to spoof the 
digital signature.  When whitelisting occurred, it would whitelist a 
particular person's signature rather than their e-mail address.

I'm not sure if the CRI framework provides for this or not as I have a hard 
time keeping up with things (just as many in this list apparently do).

Is there a brief synopsis of the current state of the CRI framework so I 
can refresh my memory on everything? (Which would be much better than 
having to re-read all the CRI messages. ;-)

-Art
-- 
Art Pollard
http://www.lextek.com/
Suppliers of High Performance Text Retrieval Engines.

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