Re: [Asrg] Spam as a symptom of sender/recipient imbalance.

"Jon Kyme" <jrk@merseymail.com> Thu, 05 June 2003 18:26 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 OAA09784 for <asrg-archive@odin.ietf.org>; Thu, 5 Jun 2003 14:26:51 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h55IQPs28827 for asrg-archive@odin.ietf.org; Thu, 5 Jun 2003 14:26:25 -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 h55IQPB28824 for <asrg-web-archive@optimus.ietf.org>; Thu, 5 Jun 2003 14:26:25 -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 OAA09774; Thu, 5 Jun 2003 14:26:20 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NzPY-0001ya-00; Thu, 05 Jun 2003 14:24:28 -0400
Received: from ietf.org ([132.151.1.19] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19NzPX-0001yX-00; Thu, 05 Jun 2003 14:24: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 h55IE1B28212; Thu, 5 Jun 2003 14:14:01 -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 h55IDpB28195 for <asrg@optimus.ietf.org>; Thu, 5 Jun 2003 14:13:51 -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 OAA09063 for <asrg@ietf.org>; Thu, 5 Jun 2003 14:13:46 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NzDO-0001jw-00 for asrg@ietf.org; Thu, 05 Jun 2003 14:11:54 -0400
Received: from argon.connect.org.uk ([193.110.243.33]) by ietf-mx with esmtp (Exim 4.12) id 19NzDN-0001jt-00 for asrg@ietf.org; Thu, 05 Jun 2003 14:11:53 -0400
Received: from mmail by argon.connect.org.uk with local (connectmail/exim) id 19NzF1-0004Qw-00; Thu, 05 Jun 2003 19:13:35 +0100
In-Reply-To: <200306041227.27506.cameron@cs.sfu.ca>
Subject: Re: [Asrg] Spam as a symptom of sender/recipient imbalance.
To: Rob Cameron <cameron@cs.sfu.ca>
From: Jon Kyme <jrk@merseymail.com>
Cc: ASRG <asrg@ietf.org>
X-Mailer: [ConnectMail 3.5.5]
X-connectmail-Originating-IP: 12.81.87.167
Message-Id: <E19NzF1-0004Qw-00@argon.connect.org.uk>
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, 05 Jun 2003 19:13:35 +0100

> 
> The notion of sender/recipient imbalance then becomes a theory
> that at once helps explain spam and also predicts that the
> problem of spam may be mitigated by addressing the imbalance.
> The two general ways of doing this are: (a) reducing the power of 
> senders and (b) increasing the power of recipients.   Most
> anti-spam proposals can be characterized as addressing one 
> or both of these objectives, typically at the MTA or network
> infrastructure level for approach (a) or at the MUA level for 
> approach (b).
> 
> Focussing on the sender/recipient imbalance may help avoid
> value judgments/arguments as to whether a particular instance
> of annoying e-mail is or is not spam.   As many have pointed
> out, there is a large grey area.   Care must be taken to avoid
> moving into this grey area in deploying MTA or network-level
> approaches that either classify messages as spam or senders
> as spammers.    But if these classification approaches are
> augmented by other means that address the sender/recipient
> imbalance, then there may be no need to move into the
> grey area at the infrastructure levels.
>

This imbalance exists chiefly because submission into the MTS is
under control of the sender, but transmission within the MTS
(MTA, MDA) is not (often) under any control of the "recipient".
 
> Personally, I am interested in approach (b): empowering recipients 
> through increased automation at the MUA.   I see challenge-response 
> systems as a first step in this automation, but consider that there may 
> be other benefits to MUA-level automation that ought also to be explored.
> For example, one scenario in our work is that C/R systems can
> be leveraged to perform other useful functions such as automated
> change-of-address negotiation (whitelist/address book updating).
> 
> Nevertheless, it is very important that MTA and network-based
> approaches also be developed.    In the short term, MUA-based
> approaches will not help with network traffic reduction.

Any approach which propagates "recipient" policy (and control) upstream
(towards the sender) will reduce the imbalance you identify. 
MUA based approaches which do not modulate the upstream MTS can have only
limited utility.

> 
> Over the long term, we will continue to need asynchronous
> text-based messaging.  But we will need to ensure that the
> great power of automation that senders may employ in generating
> messages is matched by a corresponding power of recipients
> to automate responses when and as appropriate.
> 

Quite, but what kind of responses?




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