Re: [Asrg] seeking comments on new RMX article

"Alan DeKok" <aland@freeradius.org> Mon, 05 May 2003 16:09 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 MAA06577 for <asrg-archive@odin.ietf.org>; Mon, 5 May 2003 12:09:33 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h45GHbO13932 for asrg-archive@odin.ietf.org; Mon, 5 May 2003 12:17:37 -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 h45GHb813929 for <asrg-web-archive@optimus.ietf.org>; Mon, 5 May 2003 12:17:37 -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 MAA06550; Mon, 5 May 2003 12:09:03 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CiYY-0006mF-00; Mon, 05 May 2003 12:11:10 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19CiYX-0006m4-00; Mon, 05 May 2003 12:11:09 -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 h45FvC812008; Mon, 5 May 2003 11:57:12 -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 h45Fu5811971 for <asrg@optimus.ietf.org>; Mon, 5 May 2003 11:56: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 LAA06096 for <asrg@ietf.org>; Mon, 5 May 2003 11:47:17 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19CiDT-0006e4-00 for asrg@ietf.org; Mon, 05 May 2003 11:49:23 -0400
Received: from giles.striker.ottawa.on.ca ([192.139.46.36] helo=mail.nitros9.org ident=root) by ietf-mx with esmtp (Exim 4.12) id 19CiDN-0006e1-00 for asrg@ietf.org; Mon, 05 May 2003 11:49:18 -0400
Received: from localhost ([127.0.0.1] helo=giles.striker.ottawa.on.ca ident=aland) by mail.nitros9.org with esmtp (Exim 3.34 #1) id 19CiOf-0006dc-00 for asrg@ietf.org; Mon, 05 May 2003 12:00:57 -0400
From: Alan DeKok <aland@freeradius.org>
To: asrg@ietf.org
Subject: Re: [Asrg] seeking comments on new RMX article
In-Reply-To: Your message of "Mon, 05 May 2003 08:05:36 PDT." <194902879171.20030505080536@brandenburg.com>
Message-Id: <E19CiOf-0006dc-00@mail.nitros9.org>
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, 05 May 2003 12:00:57 -0400

Dave Crocker <dhc@dcrocker.net> wrote:
> Spam is about filtering bad guys.  RMX is about labeling good guys.
> 
> Hence, with RMX, you still know nothing about bad guys.

  I don't quite agree.

> How does it help to control spam if you continue to know nothing about
> the bad guys?

  Right now, we have a pool of SMTP originators.  The pool contains
both good guys, and bad guys.  It's difficult and expensive for any
recipient to distinguish between them.

  With tools like RMX, a recipient can easily seperate the pool into
"accountable" originators, and "unknown" originators.  This means that
the bad guys are more likely to be marked as bad guys, and the good
guys less likely to be so marked.  While this doesn't give you direct
information about the bad guys, it does give you indirect information:
They're not the good guys.

  In summary, RMX allows us to increase our confidence in the marking
probability for bad guys.

> AD>   For RMX systems, you can safely be more liberal in filtering
> AD> messages, because you have some level of confidence that any spam
> AD> coming from RMX systems will be traceable and accountable.  That
> AD> doesn't seem like a bad thing to me.
> 
> What does this mean, exactly?  A different set of filters for RMX-based
> mail?  The idea of maintaining two rulesets is a bit daunting.  Seems
> unlikely to scale.

  I don't see why.  Run spam assassin, and for messages from RMX
systems, set the "spam" threshold high, so that it's more forgiving.
For messages from non-RMX systems, set it low, so it's less forgiving.

  Maintaining two numbers shouldn't be difficult for a seasoned system
administrator.

> On the modern Internet, all of the mail posting semantics are achieved
> with SMTP.

  That's nice, but it leads me to a few questions:

  - What changes, if any, may be made to a recipient MTA or MUA, in
order to fight spam?

  - What changes, if any, may be made to an originating MTA or MUA, in
order to fight spam?

  From what I can tell, your answer to the second question appears to
be "None".  If the answer to the first question is also "None", then
I don't see why we're pretending we want to solve the spam problem.

> AD>  An additional one is
> AD> mail via a web interface.
> 
> oh boy. now you are going to propose an array of non-standard user
> interfaces as an email posting protocol?

  No... I'm saying that mobile users can today choose methods other
than SMTP for sending mail.  They're ugly, they're awkward, but
they're also proven to work for thousands of people.


  And as someone who's inundated with spam, I have *no* problem with a
local site policy saying "people who lie about their originating
domain go into the bit-bucket with the spammers."  That's my
perogative, and I believe that with systems like RMX, many recipient
MTA's will be making similar choices.  Mobile users who refuse to use
VPN's will then discover that most of their mail gets bounced.

> By way of seeking something constructive out of this, would someone who
> believes there are viable alternatives to SMTP 

  I believe there are viable alternatives to naked, un-accountable
SMTP for mobile users.  VPN's, authenticated relaying, etc., all
exist, and are in wide-spread deployment.

  What I'm missing about the "mobile user & naked SMTP" problem is
why, as the recipient of such email, it's *my* problem to filter out
mobile users from the spammers who use similar methods.  Is it really
that difficult or contentious to ask mobile users to use a VPN?


> -- and that they will
> 
>      a) solve or at least reduce the spam problem,

  Allow MTA's to verify the originator of the email?

>      b) match SMTP's functionality, and

  SMTP over a VPN seems to be a good solution.

>      c) stand some chance of being adopted by the Internet's 100 million
>      users

  Companies are selling these solutions today for mobile users, and
are making a living at it.

> please put forward a technical specification of this "viable"
> alternative, so that it moves from a general idea into something
> concrete.

  I'm not proposing that we scrap SMTP.  But I still haven't heard
reasons why naked SMTP is the ONLY possible method for mobile users to
send email.  Alternatives exist today, and are in wide-spread
deployment.

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