[Asrg] C/R Thoughts: Take 1

"Eric Dean" <eric@purespeed.com> Sun, 11 May 2003 23:03 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 TAA15221 for <asrg-archive@odin.ietf.org>; Sun, 11 May 2003 19:03:26 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4BMSgJ23036 for asrg-archive@odin.ietf.org; Sun, 11 May 2003 18:28:42 -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 h4BMSgB23033 for <asrg-web-archive@optimus.ietf.org>; Sun, 11 May 2003 18:28:42 -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 TAA15215; Sun, 11 May 2003 19:02:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19EzsF-0003PC-00; Sun, 11 May 2003 19:04:56 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19EzsF-0003P9-00; Sun, 11 May 2003 19:04:55 -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 h4BMP6B22967; Sun, 11 May 2003 18:25: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 h4BMO5B22925 for <asrg@optimus.ietf.org>; Sun, 11 May 2003 18:24:05 -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 SAA15164 for <asrg@ietf.org>; Sun, 11 May 2003 18:58:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Eznn-0003ON-00 for asrg@ietf.org; Sun, 11 May 2003 19:00:19 -0400
Received: from ns2.tidalwave.net ([66.77.68.8] helo=mailgate.purespeed.com) by ietf-mx with esmtp (Exim 4.12) id 19Eznm-0003OH-00 for asrg@ietf.org; Sun, 11 May 2003 19:00:19 -0400
Received: from purespeed.com (mail.purespeed.com [66.77.69.8]) by mailgate.purespeed.com (Postfix Relay Hub) with ESMTP id DCBD513CAD for <asrg@ietf.org>; Sun, 11 May 2003 19:03:02 -0400 (EDT)
Received: from HOMEY [68.100.19.195] by purespeed.com (SMTPD32-7.13) id A62238F013E; Sun, 11 May 2003 19:00:50 -0400
From: Eric Dean <eric@purespeed.com>
To: asrg@ietf.org
Message-ID: <MBEKIIAKLDHKMLNFJODBKEDIFCAA.eric@purespeed.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 7bit
Subject: [Asrg] C/R Thoughts: Take 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, 11 May 2003 19:02:58 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

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