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

Yakov Shafranovich <research@solidmatrix.com> Mon, 12 May 2003 20:47 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 QAA03599 for <asrg-archive@odin.ietf.org>; Mon, 12 May 2003 16:47:27 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4CKD8p31484 for asrg-archive@odin.ietf.org; Mon, 12 May 2003 16:13:08 -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 h4CKD8B31481 for <asrg-web-archive@optimus.ietf.org>; Mon, 12 May 2003 16:13:08 -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 QAA03590; Mon, 12 May 2003 16:46:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FKE9-0004Zj-00; Mon, 12 May 2003 16:48:54 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FKE9-0004Zg-00; Mon, 12 May 2003 16:48:53 -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 h4CKBMB31312; Mon, 12 May 2003 16:11:22 -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 h4CKAOB31259 for <asrg@optimus.ietf.org>; Mon, 12 May 2003 16:10:24 -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 QAA03488 for <asrg@ietf.org>; Mon, 12 May 2003 16:44:13 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FKBW-0004XW-00 for asrg@ietf.org; Mon, 12 May 2003 16:46:10 -0400
Received: from 000-238-299.area5.spcsdns.net ([68.27.170.48] helo=68.27.170.48) by ietf-mx with smtp (Exim 4.12) id 19FKBU-0004XS-00 for asrg@ietf.org; Mon, 12 May 2003 16:46:09 -0400
Message-Id: <5.2.0.9.2.20030512164334.00bd7bf8@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: Eric Dean <eric@purespeed.com>, asrg@ietf.org
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: Re: [Asrg] C/R Thoughts: Take 1
In-Reply-To: <MBEKIIAKLDHKMLNFJODBKEDIFCAA.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: Mon, 12 May 2003 16:45:27 -0400

I have been in touch with a company called MailCurcuit.com, who currently 
operates a C/R system. They are willing to provide information on their own 
experience with different aspects of C/R systems, as well as statistics. I 
will be passing along some statistical information from them.

Yakov

At 07:02 PM 5/11/2003 -0400, Eric Dean wrote:

>Per the request to put together ideas regarding C/R systems below is a brief
>inventory of some possible areas for a C/R standardization effort.  I'm not
>advocating standardization of any of these...but rather identifying areas
>that to some are obvious.  The MUST, SHALLs, and MAY's can follow later:
>
>There are a few general components to C/R or any email system
>1) Message receipt:
>-Permit: Whitelist sender, message scoring...automatically delivers to
>user's Inbox
>-Drop: Blacklist, message scoring...drops message
>-Pend: Hold message in queue for further C/R validation
>
>2) Sender Challenge
>-Sender name: Should the original sender's name be sent in the reply to of a
>challenge message or should a common name be used.  For examples, bounces
>use <>.  C/R systems might avoid C/R loops using a convention.
>-Subject header: Should the original subject header be preserved or a new
>subject header be sent.  C/R systems might avoid C/R loops using a
>convention.
>-Actions: Should a sender be allowed to merely confirm or can they also
>report that they did not originate the message..or possibly report to an
>authority
>-Challenge Bounce: There are a variety of SMTP errors that can be
>returned...should some be considered to result in an automatic message drop?
>Blacklisting a sender may result in a later valid user actual taking that
>user namespace.
>
>3) List Detection
>-Sender Header: What methods other than the sender header should be used to
>detect a mailing list thus disabling C/R messages?
>
>4) Sender Response
>-HTTP: Are there recommended methods for producing verification URLs?
>Certainly they should be unguessable.  Should they have a short TTL or have
>a persistent convention?
>-Access Codes: Should a barely legible, anti-bot access code also be
>supplied?
>-SMTP: Should SMTP responses be supported?

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