RE: [Asrg] seeking comments on new RMX article

"Eric D. Williams" <eric@infobro.com> Tue, 06 May 2003 18:35 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 OAA02452 for <asrg-archive@odin.ietf.org>; Tue, 6 May 2003 14:35:41 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h46IiIO17244 for asrg-archive@odin.ietf.org; Tue, 6 May 2003 14:44:18 -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 h46IiI817241 for <asrg-web-archive@optimus.ietf.org>; Tue, 6 May 2003 14:44: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 OAA02425; Tue, 6 May 2003 14:35:11 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7JU-0001HH-00; Tue, 06 May 2003 14:37:16 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19D7JU-0001HE-00; Tue, 06 May 2003 14:37:16 -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 h46If8817062; Tue, 6 May 2003 14:41: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 h46IeU817004 for <asrg@optimus.ietf.org>; Tue, 6 May 2003 14:40:30 -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 OAA02282 for <asrg@ietf.org>; Tue, 6 May 2003 14:31:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19D7Fp-0001Fa-00 for asrg@ietf.org; Tue, 06 May 2003 14:33:29 -0400
Received: from black.infobro.com ([63.71.25.39] helo=infobro.com) by ietf-mx with smtp (Exim 4.12) id 19D7Fo-0001Ep-00 for asrg@ietf.org; Tue, 06 May 2003 14:33:28 -0400
Received: from red (unverified [207.199.136.153]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id <B0002399194@infobro.com>; Tue, 06 May 2003 14:33:05 -0400
Received: by localhost with Microsoft MAPI; Tue, 6 May 2003 14:33:12 -0400
Message-ID: <01C313DC.6BF929D0.eric@infobro.com>
From: "Eric D. Williams" <eric@infobro.com>
To: 'Dave Crocker' <dcrocker@brandenburg.com>, Hadmut Danisch <hadmut@danisch.de>
Cc: "asrg@ietf.org" <asrg@ietf.org>
Subject: RE: [Asrg] seeking comments on new RMX article
Organization: Information Brokers, Inc.
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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: Tue, 06 May 2003 14:32:16 -0400
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

On Tuesday, May 06, 2003 1:39 PM, Dave Crocker [SMTP:dhc@dcrocker.net] wrote:
8<...>8
> The reason that I refer to RMX as a point solution, rather than
> something with a real potential for getting at the core of spam, is
> because it "only" attempts to deal with From-field spoofing.
>
> Spoofing is bad, but it is not at all the core problem with spam.

But spoofing is one of the plethora of problems that are found with 'spam'.

> Spam is about content policies and author policies. RMX does nothing
> about either of these.

If those are the basis problems then there is no technical solution except 
filtering.  Those approaches, IMHO, also has merit and should be pursued 
vigorously.  I don't believe there is a silver bullet for 'spam'.  I feel there 
must be an overall architecture developed that addresses multiple points.  RMX 
is, as you state, a point solution; I think the architecture for dealing with 
'spam' may require multiple point solutions to be effective.

> Eliminate all spoofing and you are left with massive amounts of spam.

I agree, but that also represents a reduction in spoofed 'spam' (perhaps given 
your adaptability metric offset by other methods).  It is a proposal for an 
incremental but deployment could be coordinated with other proposals that make 
up an overall architecture.

> And, by the way, in the off-chance that RMX actually does achieve
> wide-scale deployment, the folks who are currently doing spoofing will
> simply move on to other techniques.

That may be true but, it is unknowable what other techniques those will be and 
unknowable what other techniques will evolve to counteract other proposals. 
 Given 'spammer' adaptability a viable method of reducing the universe of 
methods that are usable is a plus, to me.

> Note that there is nothing to prevent a spammer from hosting an MTA and
> creating RMX records.  They might not be able to do that for aol.com but
> they CAN do it for a0l.biz, supposedly-honest.net, and an infinite
> number of other domains.

True.  I think that misses the mark though, there will always be an infinite 
number of domains and I don't think RMX purports to eliminate 'spamming' MTAs. 
 The question then becomes for me "Am I establishing controls to counteract 
spam from the appropriate MTAs?"

> Like IDENT, RMX relies on a model of strict, system-wide control.
> Unfortunately, the diversity of the net means that it is essentially
> impossible to enforce the kinds of controls that are required by such
> proposals.

That is also true.  Do you know of a distributed control methodology that can 
enforce controls at the edges OR, allow better enforcement at the/my policy 
boundary?

>
> HD> Again, please inform yourself before posting.
>
> I will return the favor, by suggesting that folks inform themselves
> about the realities of Internet-scale operations, Internet-scale
> deployment physics, and Internet-scale spammer adaptability.

I feel RMX can be evolved and will scale.  I concur and think the deployment 
physics of RMX should be explored in greater depth.  I would like a pointer to 
any prior work done with respect to 'spammer' adaptability outside my own 
anecdotal references and historical perspective.

> Then, perhaps, we will not be presented with localized, near-term
> proposals that will have no impact on large-scale, long-term spamming.

I am not sure which proposals will be localized and near-term and will have no 
impact, yet.  I have not seen much evolution in the proposals.  I am not sure 
whether RMX should be considered localized although I do agree that there may 
be an issue of near-term adoption that must be explored to determine viability 
(to which Vernon has alluded) I do not know what the 'number' is for any 
proposal.

It may be useful to consider whether any proposal will not be localized in as 
much as policy controls will constitute the ACTUAL manifestation of 'spam' 
controls.  Whether in the core or at the edges.

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