RE: [Asrg] C/R - What people say

Yakov Shafranovich <research@solidmatrix.com> Fri, 16 May 2003 00:00 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 UAA27903 for <asrg-archive@odin.ietf.org>; Thu, 15 May 2003 20:00:18 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h4FNRXR12168 for asrg-archive@odin.ietf.org; Thu, 15 May 2003 19:27:33 -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 h4FNRXB12165 for <asrg-web-archive@optimus.ietf.org>; Thu, 15 May 2003 19:27:33 -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 TAA27882; Thu, 15 May 2003 19:59:48 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GSfO-00034B-00; Thu, 15 May 2003 20:01:42 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19GSfO-000345-00; Thu, 15 May 2003 20:01:42 -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 h4FNGWB11832; Thu, 15 May 2003 19:16:32 -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 h4FNFIB11810 for <asrg@optimus.ietf.org>; Thu, 15 May 2003 19:15:18 -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 TAA27681 for <asrg@ietf.org>; Thu, 15 May 2003 19:47:33 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19GSTY-00031j-00 for asrg@ietf.org; Thu, 15 May 2003 19:49:28 -0400
Received: from 000-232-794.area5.spcsdns.net ([68.27.148.131] helo=68.27.148.131) by ietf-mx with smtp (Exim 4.12) id 19GSTQ-00031U-00 for asrg@ietf.org; Thu, 15 May 2003 19:49:22 -0400
Message-Id: <5.2.0.9.2.20030515193543.00b3c180@std5.imagineis.com>
X-Sender: research@solidmatrix.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
To: asrg@ietf.org, Eric Dean <eric@purespeed.com>
From: Yakov Shafranovich <research@solidmatrix.com>
Subject: RE: [Asrg] C/R - What people say
In-Reply-To: <Pine.GSO.4.10.10305151801230.216-100000@nber5.nber.org>
References: <200305152059.h4FKxreC027669@calcite.rhyolite.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: Thu, 15 May 2003 19:48:50 -0400

At 06:14 PM 5/15/2003 -0400, Daniel Feenberg wrote:

>On Thu, 15 May 2003, Vernon Schryver wrote:
>
> >
> > What is the real goal a C/R system?  I thought it had something to do
> > with reducing "spam."  How does spam differ from any other bulk mail
> > except in whether it is solicited?
> >
> > As I've pointed out, a substantal amount of the unsolicited bulk
> > mail in my traps has headers just like mail from other "lists"
> > including this one.
> >
> > If a C/R system only stops spam from transient, "hit-and-run" systems
> > that do not stand still long enough to receive and answer a challenge,
> > it won't be very impressive.
> >
>
>I was hoping someone would bring this up. I didn't because it seemed like
>I was missing something. Did I also miss the discussion of how two C/R
>systems would interact if both sender and receiver have them? This must
>have come up in real life - do the users of these systems have experience
>to relate?
>
>I would have thought the role of standardization in the C/R system would
>not be to standardize the challenge, which needs to be non-standardized so
>that automated systems can't respond effectively, but rather to provide an
>effective route around the C/R system for legitimate lists.

At this point, as outlined, Eric is proposing an automated protocol for C/R 
not for internal use but for actually responding to challenges 
automatically. As I mentioned before, we need to better define the goals of 
C/R. Is is to make sure that senders are legit, or is it going to an extra 
level to making sure the sender is human (essentially creating a Turing 
Test). As for having spammers set up automatic responders, see TDMA FAQ, 
section 1.1 (http://tmda.net/faq.cgi?req=all)

------snip--------
"1.1. Can't spammers just setup an auto-responder to defeat TMDA? *

In theory yes, but in practice this is not likely to happen. Most SPAM is 
unrepliable, so TMDA's confirmation requests are never delivered to them. 
They use non-valid return addresses as to not incur the cost of the 
tremendous number of bounces they generate. Using a valid return address to 
process all the bounces looking for confirmation messages to auto-reply to 
would defeat their economies of scale. It would also make them easy to 
block, track down and report, sue, etc. In short, trying to thwart TMDA in 
this manner would defeat the cost-effectiveness of the bulk-mailing 
process. Simple economics keep us safe.

But should these facts change, TMDA could modify its (currently very 
simple) challenge/response to make it more difficult for a computer to 
auto-reply to. The level of difficulty could increase as much as is 
necessary for the sender to prove their humanity and legitimacy.

The idea is to keep the challenge/response as simple as possible to avoid 
inconveniencing legitimate senders, while at the same time difficult enough 
to thwart an automated response system. At the present time, TMDA offers 
the ability to confirm by a simple e-mail reply, or by clicking on a URL. 
There is no evidence to suggest that a more challenging procedure is even 
close to necessary.

If spammers do resort to auto-confirmation however, we've won a huge battle 
for the community by raising the bar and forcing them to leave a breadcrumb 
trail leading back to their lair. As the focus on legislation continues, 
and spamming becomes an increasingly illegal activity, who will take these 
great risks for such a little reward? "
-----snip--------

Perhaps the primary purpose of C/R should be counteracting the basic flaw 
in SMTP that allows anyone to send email without verifying who the sender 
is? Or perhaps not? Disabling the ability for automated systems to be able 
to send email is something we might not want to do. There are also various 
other issues, such as the ones raised in section 7.1 of RFC 2821 which as 
we mentioned apply to mailing lists.

Yakov 

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