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

Yakov Shafranovich <research@solidmatrix.com> Sun, 18 May 2003 18:58 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 OAA14462 for <asrg-archive@odin.ietf.org>; Sun, 18 May 2003 14:58:53 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4IIRS630024 for asrg-archive@odin.ietf.org; Sun, 18 May 2003 14:27:28 -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 h4IIRSB30021 for <asrg-web-archive@optimus.ietf.org>; Sun, 18 May 2003 14:27: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 OAA14435; Sun, 18 May 2003 14:58:22 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HTOH-0004sl-00; Sun, 18 May 2003 15:00:13 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19HTOG-0004si-00; Sun, 18 May 2003 15:00:12 -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 h4IIQAB29930; Sun, 18 May 2003 14:26:10 -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 h4IIP2B29805 for <asrg@optimus.ietf.org>; Sun, 18 May 2003 14:25:02 -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 OAA14392 for <asrg@ietf.org>; Sun, 18 May 2003 14:55:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HTLv-0004rY-00 for asrg@ietf.org; Sun, 18 May 2003 14:57:47 -0400
Received: from 000-230-497.area5.spcsdns.net ([68.27.139.120] helo=68.27.139.120) by ietf-mx with smtp (Exim 4.12) id 19HTLt-0004rV-00 for asrg@ietf.org; Sun, 18 May 2003 14:57:46 -0400
Message-Id: <5.2.0.9.2.20030518145551.02f9ce00@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: <MBEKIIAKLDHKMLNFJODBCEJNFDAA.eric@purespeed.com>
References: <p06001255baeb2b933a1a@[192.168.1.104]>
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: Sun, 18 May 2003 14:58:46 -0400

At 10:34 AM 5/18/2003 -0400, Eric Dean wrote:

> > 2. C/R systems need to have a standard way of identifying themselves
> > as such.  This avoids loops, and it let's us shunt them into an
> > appropriate handling queue.
>
>Yes, if a message has the C/R headers..it shouldn't be challenged.  Only
>challenge messages should use C/R headers.  We've discussed the issue
>regarding spammers using them...not using them.  The other recommendation is
>that the system be stateful and not constantly return the challenge
>messages.  If you send my demo account 20 messages, you get one challenge
>back.  Now, that's implementation-specific.  I would not suggest that a
>protocol require a system to be stateful..if mentioned at all.  However, I
>would recommend that C/R headers result in a suppressed challenge to avoid
>loops.

One thing I wanted to mention is that a C/R system that has a white-list of 
verified senders, should probably verify the senders again every X months.

> > 3. As I've said before--any system that requires you to do something
> > other than just reply (e.g. read a graphic) needs to meet
> > accessibility standards.
>
>Yes, agreed.  And therefore, vendors that do stupid things will not sell
>their product and Darwinian nature will run it's course.  I'm not sure that
>we want to address the body or content of the challenge message..just the
>challenge headers.  Again, these are just my thoughts and am widely open to
>counter-thoughts.

A Turing test may not be able to meet accessibility standards but again are 
we seeking to distinguish between man and machine, or verify the email address.

> > 4. If you have a web based confirmation system, you should also have
> > an email-based one.  The fact that I can send you email does not mean
> > that I can access your web site.  (Think China, think road-warrier,
> > think third world.)
>
>Agreed.  I'm not trying to specify a web-based authentication method here or
>an SMTP-reply one.  I agree there should be such methods.  I guess, if the
>industry is naturally going in a certain direction, I would not intrude on
>their liberties.  However, if we all want to interwork...which is really
>what I am looking to define...an Interworking for C/R Systems...then  we
>should identify the criteria.  Come to think of it, that's ALL I'm
>considering.  I just to provide an interworking method and not dictate to
>vendors how they should build their own systems...the market will figure
>that out.
>
>As a result, I will probably rename the draft to a C/R System Interworking
>document.

Since the C/R systems operate over SMTP, all parts of it should operate 
over SMTP including the replies.

Yakov 

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