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

"Peter Kay" <> Wed, 04 June 2003 21:09 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id RAA12811 for <>; Wed, 4 Jun 2003 17:09:13 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h54L8mv21755 for; Wed, 4 Jun 2003 17:08:48 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h54L8mB21752 for <>; Wed, 4 Jun 2003 17:08:48 -0400
Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id RAA12796; Wed, 4 Jun 2003 17:08:43 -0400 (EDT)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h54L65B20786; Wed, 4 Jun 2003 17:06:05 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h54L51B20699 for <>; Wed, 4 Jun 2003 17:05:01 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id RAA12414 for <>; Wed, 4 Jun 2003 17:04:56 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19NfPX-0000Mh-00 for; Wed, 04 Jun 2003 17:03:08 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19NfPX-0000MW-00 for; Wed, 04 Jun 2003 17:03:07 -0400
Received: from [] by (SMTPD32-7.14) id AF35561007A; Wed, 04 Jun 2003 11:05:57 -1000
Received: from ( 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 <>
To: Rob Cameron <>,
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by id h54L52B20700
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>
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

> -----Original Message-----
> From: Rob Cameron [] 
> Sent: Wednesday, June 04, 2003 9:27 AM
> To:
> 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 mailing list