Re: [Asrg] C/R Thoughts: Take 1

Yakov Shafranovich <research@solidmatrix.com> Wed, 14 May 2003 02:11 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 WAA07189 for <asrg-archive@odin.ietf.org>; Tue, 13 May 2003 22:11:13 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4E1bVH18957 for asrg-archive@odin.ietf.org; Tue, 13 May 2003 21:37:31 -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 h4E1bVB18954 for <asrg-web-archive@optimus.ietf.org>; Tue, 13 May 2003 21:37:31 -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 WAA07173; Tue, 13 May 2003 22:10:43 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Fll1-0001fq-00; Tue, 13 May 2003 22:12:39 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Fll0-0001fn-00; Tue, 13 May 2003 22:12:38 -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 h4E1YaB18083; Tue, 13 May 2003 21:34:36 -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 h4E1VMB17978 for <asrg@optimus.ietf.org>; Tue, 13 May 2003 21:31:22 -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 WAA07073 for <asrg@ietf.org>; Tue, 13 May 2003 22:04:34 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Flf4-0001dY-00 for asrg@ietf.org; Tue, 13 May 2003 22:06:30 -0400
Received: from 000-246-276.area7.spcsdns.net ([68.27.201.151] helo=68.27.201.151 ident=trilluser) by ietf-mx with smtp (Exim 4.12) id 19Flf2-0001dV-00 for asrg@ietf.org; Tue, 13 May 2003 22:06:29 -0400
Message-Id: <5.2.0.9.2.20030513220542.00ba55b8@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: [Asrg] C/R Thoughts: Take 1
In-Reply-To: <3EC19906.7080600@harvee.org>
References: <MBEKIIAKLDHKMLNFJODBIEKOFCAA.eric@purespeed.com> <MBEKIIAKLDHKMLNFJODBIEKOFCAA.eric@purespeed.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, 13 May 2003 22:07:11 -0400

At 09:16 PM 5/13/2003 -0400, Eric S. Johansson wrote:

>Eric Dean wrote:
>
>>>I personally think that the intent of the C/R systems is to make
>>>sure that
>>>the originating email is valid. Thus it would make sense to have an
>>>automatic protocol for verification which can be utilized by
>>>systems to do
>>>so.
>>
>>Yes, if we could come up with a standard for C/R, then it would seem
>>appropriate that a mail client would be able to auto-verify any challenge
>>that came in response to a recipient that had been recently sent a message.
>>I'll throw out a light framework within the next day or two that we can
>>start insulting.  Requires coffee and post-midnight to truly think.
>
>we went over this terrain in the camram project a couple of years 
>ago.  Anytime you make a response something that can be auto responded to, 
>you create a hole for spammers.  one thing I believe to be very important 
>is a list of signatures for messages recently sent and the challenge 
>should contain a matching signature for the message it is 
>challenging.  That way, when the challenge is handled, the mail user agent 
>can verify that the client really did send a message the challenge was 
>returned for by matching signature and destination address.
>
>This is part of protocol I'm using for handling postage due notices 
>automatically within camram.  I'll elaborate more tomorrow if folks are 
>interested.

As I mentioned before what we are trying to figure out is the intent of C/R 
systems. We are aware that an automatic procotol can create a hole for 
spammers but at least the spammers must have a valid return address. The 
question remains: are C/R systems intended to verify that the message 
arrived from a valid email address or are they intended to make sure the 
sender is human?

Yakov

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