RE: [Asrg] Spam as a symptom of sender/recipient imbalance.
"Peter Kay" <peter@titankey.com> Wed, 04 June 2003 21: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 RAA12811 for <asrg-archive@odin.ietf.org>; Wed, 4 Jun 2003 17:09:13 -0400 (EDT)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h54L8mv21755 for asrg-archive@odin.ietf.org; Wed, 4 Jun 2003 17:08:48 -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 h54L8mB21752 for <asrg-web-archive@optimus.ietf.org>; Wed, 4 Jun 2003 17:08:48 -0400
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 RAA12796; Wed, 4 Jun 2003 17:08:43 -0400 (EDT)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h54L65B20786; Wed, 4 Jun 2003 17:06:05 -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 h54L51B20699 for <asrg@optimus.ietf.org>; Wed, 4 Jun 2003 17:05:01 -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 RAA12414 for <asrg@ietf.org>; Wed, 4 Jun 2003 17:04:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19NfPX-0000Mh-00 for asrg@ietf.org; Wed, 04 Jun 2003 17:03:08 -0400
Received: from imail.centuryc.net ([216.30.168.20] helo=isp-appsvr01.centuryc.com) by ietf-mx with esmtp (Exim 4.12) id 19NfPX-0000MW-00 for asrg@ietf.org; Wed, 04 Jun 2003 17:03:07 -0400
Received: from cybercominc.com [66.91.134.126] by isp-appsvr01.centuryc.com (SMTPD32-7.14) id AF35561007A; Wed, 04 Jun 2003 11:05:57 -1000
Received: from a66b91n134client123.hawaii.rr.com (66.91.134.123) by cybercominc-zzt with SMTP; Wed, 04 Jun 2003 21:09:03 GMT
X-Titankey-e_id: <96e12b26-161b-4ff3-bcae-14cd07107606>
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [Asrg] Spam as a symptom of sender/recipient imbalance.
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Message-ID: <DD198B5D07F04347B7266A3F35C42B0B0FD021@io.cybercom.local>
Thread-Topic: [Asrg] Spam as a symptom of sender/recipient imbalance.
Thread-Index: AcMq1bc5XvPZFcHJSpm9hZ7OeE/9swABwZRA
From: Peter Kay <peter@titankey.com>
To: Rob Cameron <cameron@cs.sfu.ca>, asrg@ietf.org
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h54L52B20700
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: Wed, 04 Jun 2003 11:04:28 -1000
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
I think you're right on. I believe that sooner or later, some type of C/R will be the way email gets passed around. One may argue (and have a good case) to say that today's C/R are clunky and don't work well, but ultimately they empower the recipient in a way that addresses the imbalance. > -----Original Message----- > From: Rob Cameron [mailto:cameron@cs.sfu.ca] > Sent: Wednesday, June 04, 2003 9:27 AM > To: asrg@ietf.org > Subject: [Asrg] Spam as a symptom of sender/recipient imbalance. > > > 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 > > > _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg