[Asrg] Spam as a symptom of sender/recipient imbalance.
Rob Cameron <email@example.com> Wed, 04 June 2003 19:35 UTC
Received: from www1.ietf.org (ietf.org [126.96.36.199] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09381 for <firstname.lastname@example.org>; Wed, 4 Jun 2003 15:35:45 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54JZIg13567 for email@example.com; Wed, 4 Jun 2003 15:35:18 -0400
Received: from ietf.org (odin.ietf.org [188.8.131.52]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54JZIB13564 for <firstname.lastname@example.org>; Wed, 4 Jun 2003 15:35:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [184.108.40.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09356; Wed, 4 Jun 2003 15:35:15 -0400 (EDT)
Received: from ietf-mx ([220.127.116.11]) by ietf-mx with esmtp (Exim 4.12) id 19Ne0k-0007ME-00; Wed, 04 Jun 2003 15:33:26 -0400
Received: from ietf.org ([18.104.22.168] helo=www1.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19Ne0j-0007MB-00; Wed, 04 Jun 2003 15:33:25 -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 h54JS7B13213; Wed, 4 Jun 2003 15:28:07 -0400
Received: from ietf.org (odin.ietf.org [22.214.171.124]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54JRWB13189 for <email@example.com>; Wed, 4 Jun 2003 15:27:32 -0400
Received: from ietf-mx (ietf-mx.ietf.org [126.96.36.199]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09050 for <firstname.lastname@example.org>; Wed, 4 Jun 2003 15:27:29 -0400 (EDT)
Received: from ietf-mx ([188.8.131.52]) by ietf-mx with esmtp (Exim 4.12) id 19NdtE-0007GV-00 for email@example.com; Wed, 04 Jun 2003 15:25:40 -0400
Received: from cs.sfu.ca ([184.108.40.206] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19NdtD-0007GS-00 for firstname.lastname@example.org; Wed, 04 Jun 2003 15:25:39 -0400
Received: from regula (regula [220.127.116.11]) by cs.sfu.ca (8.12.9/8.12.9) with ESMTP id h54JRRpi026416 for <email@example.com>; Wed, 4 Jun 2003 12:27:28 -0700 (PDT)
From: Rob Cameron <firstname.lastname@example.org>
Content-Type: text/plain; charset="us-ascii"
Subject: [Asrg] Spam as a symptom of sender/recipient imbalance.
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:email@example.com?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:firstname.lastname@example.org?subject=subscribe>
Date: Wed, 04 Jun 2003 12:27:27 -0700
In tackling the definition of spam, perhaps it would be useful to have a somewhat different view in which spam is considered a symptom of a deeper problem. Here is a statement I have been using to motivate e-mail research work here at SFU. "Current e-mail standards create an imbalance between senders and recipients, providing senders with the power to capture the attention of any recipient they so desire, while giving recipients little control over what appears in their inbox. The imbalance becomes most severe when the sender is a computer program sending out bulk unsolicited e-mail (spam)." 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. 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. 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. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg