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

"Eric Dean" <eric@purespeed.com> Sun, 18 May 2003 14:35 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 KAA10844 for <asrg-archive@odin.ietf.org>; Sun, 18 May 2003 10:35:20 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4IE3nv15182 for asrg-archive@odin.ietf.org; Sun, 18 May 2003 10:03:49 -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 h4IE3mB15179 for <asrg-web-archive@optimus.ietf.org>; Sun, 18 May 2003 10:03:48 -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 KAA10817; Sun, 18 May 2003 10:34:49 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HPHD-00041A-00; Sun, 18 May 2003 10:36:39 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19HPHC-000417-00; Sun, 18 May 2003 10:36: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 h4IDxFB15022; Sun, 18 May 2003 09:59:15 -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 h4IDwGB14949 for <asrg@optimus.ietf.org>; Sun, 18 May 2003 09:58:16 -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 KAA10725 for <asrg@ietf.org>; Sun, 18 May 2003 10:29:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19HPBq-00040N-00 for asrg@ietf.org; Sun, 18 May 2003 10:31:07 -0400
Received: from ns2.tidalwave.net ([66.77.68.8] helo=mailgate.purespeed.com) by ietf-mx with esmtp (Exim 4.12) id 19HPBq-00040K-00 for asrg@ietf.org; Sun, 18 May 2003 10:31:06 -0400
Received: from purespeed.com (mail.purespeed.com [66.77.69.8]) by mailgate.purespeed.com (Postfix Relay Hub) with ESMTP id 614B313B2E; Sun, 18 May 2003 10:34:41 -0400 (EDT)
Received: from HOMEY [68.100.19.195] by purespeed.com (SMTPD32-7.13) id A952F8A400D2; Sun, 18 May 2003 10:31:46 -0400
From: Eric Dean <eric@purespeed.com>
To: Kee Hinckley <nazgul@somewhere.com>
Cc: asrg@ietf.org
Subject: RE: [Asrg] C/R Thoughts: Take 1
Message-ID: <MBEKIIAKLDHKMLNFJODBCEJNFDAA.eric@purespeed.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <p06001255baeb2b933a1a@[192.168.1.104]>
Importance: Normal
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: Sun, 18 May 2003 10:34:06 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

>
> 1. C/R systems should preserve subjects through the process.  They
> can add to them if they want, but the original should be there.

I'm not sure that they should..and not sure they shouldn't.  It should be a
configuration option by the administrator to preserve the subject or
originate a new one.  Such a method would be implementation-specific and not
determined by a standard if mentioned at all.

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

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

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

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