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

"Eric Dean" <eric@purespeed.com> Tue, 13 May 2003 02:08 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 WAA11402 for <asrg-archive@odin.ietf.org>; Mon, 12 May 2003 22:08:59 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4D1Ym120537 for asrg-archive@odin.ietf.org; Mon, 12 May 2003 21:34:48 -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 h4D1YmB20534 for <asrg-web-archive@optimus.ietf.org>; Mon, 12 May 2003 21:34: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 WAA11385; Mon, 12 May 2003 22:08:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FPFL-0006Ki-00; Mon, 12 May 2003 22:10:27 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19FPFL-0006Kf-00; Mon, 12 May 2003 22:10:27 -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 h4D1SUB20321; Mon, 12 May 2003 21:28:30 -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 h4D1RuB20303 for <asrg@optimus.ietf.org>; Mon, 12 May 2003 21:27:56 -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 WAA11289 for <asrg@ietf.org>; Mon, 12 May 2003 22:01:36 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19FP8h-0006JQ-00 for asrg@ietf.org; Mon, 12 May 2003 22:03:35 -0400
Received: from ns2.tidalwave.net ([66.77.68.8] helo=mailgate.purespeed.com) by ietf-mx with esmtp (Exim 4.12) id 19FP8g-0006JN-00 for asrg@ietf.org; Mon, 12 May 2003 22:03:34 -0400
Received: from purespeed.com (mail.purespeed.com [66.77.69.8]) by mailgate.purespeed.com (Postfix Relay Hub) with ESMTP id BCB4213BAC; Mon, 12 May 2003 22:05:50 -0400 (EDT)
Received: from HOMEY [68.100.19.195] by purespeed.com (SMTPD32-7.13) id A2717A83008E; Mon, 12 May 2003 22:03:29 -0400
From: Eric Dean <eric@purespeed.com>
To: Yakov Shafranovich <research@solidmatrix.com>, asrg@ietf.org
Subject: RE: [Asrg] C/R Thoughts: Take 1
Message-ID: <MBEKIIAKLDHKMLNFJODBKEHKFCAA.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
Importance: Normal
In-reply-to: <5.2.0.9.2.20030512171321.00bd7bf8@std5.imagineis.com>
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: Mon, 12 May 2003 22:05:41 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

> We probably cannot recommend any specific implementation details
> like which
> filters should be used for message scoring,  just general guidelines.

ok..again, I'm merely inventorying the potential areas of interest..not
advocating anything in particular

> However, one problem with C/R systems is that spammers do not currently
> have an incentive to break them since there are many other ways to send
> spam. If C/R systems become wide spread, spammers will have an
> incentive to
> attack them and perhaps (gasp) even manage to break them.

Well, we better build something they can't break.  There are many, many
smart people on this list that can surely put something  together over time

> We need some
> input from live C/R systems.

We have a live C/R system and Mailcircuit is also a good source...not sure
how many other people on the list use C/R...but just about everyone knows
the vulnerabilities and limitations...often standards are discussed prior to
implementation...we have an advantage here.  I believe all would agree that
C/R should probably be tighter than current implementations..what that
results in..don't know.

> Would message scoring automatically drop messages below a certain
> threshold? Spam filters are not fool-proof and some messages
> might be lost.
> Perhaps all incoming email should be challenged or giving that as
> an option
> to the user?

ok..not trying to jump into the pool yet...just trying tom set
dimensions...not looking to take anythign off the table..jsut determing what
should be on the table

> Also, maybe a C/R system should be combined with a rDNS/RMX
> system to weed
> out invalid email addresses BEFORE a challenge is sent, in order
> to save on
> the use of computer resources.

Not sure any measures would be in conflict with one another.

> How would a whitelist handle mailing lists? What about automated computer
> programs that notify users, like Ebay's auction bots? And what about
> anonymous email, if C/R is implemented everywhere, can anyone send
> anonymous email anymore? What about opt-in email that the receiver forgot
> about the original opt-in? And email that is sent from different email
> addresses everytime (like some mailing lists)?

All of these are important tactical issues..any more?

> >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.
>
> It is not important to send the sender's name back, the email address is
> sufficient. As for bounces, a header might be used to catch that like the
> "X-BeenThere:" header used for our mailing list.

ok..that's one approach

> >-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.
>
> The challenge should contain at the least a copy of the header somewhere
> within the message so the sender can figure out what the challenge is in
> relation to. As for loops, use headers.

ok..as for the rest of your contributions.  I'm not particularly interested
in debating issues but rather discuss what issues we should debate.  I'm
sure  there will be spirited discussions to come..but for now..I want to
know what should get included within in a draft framework.



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