Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <> Wed, 03 February 2010 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D56028C0EE for <>; Wed, 3 Feb 2010 08:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xR0BKWwp7JUB for <>; Wed, 3 Feb 2010 08:25:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A9C0C28C123 for <>; Wed, 3 Feb 2010 08:25:18 -0800 (PST)
Received: from ( []) by (Switch-2.2.6/Switch-2.2.0) with ESMTP id o13GPj120988 for <>; Wed, 3 Feb 2010 16:25:47 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 11:25:42 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 3 Feb 2010 11:25:42 -0500
Message-ID: <>
Date: Wed, 3 Feb 2010 11:25:34 -0500
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Feb 2010 16:25:42.0527 (UTC) FILETIME=[87C130F0:01CAA4ED]
Subject: Re: [Asrg] Adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 03 Feb 2010 16:25:20 -0000

Ian Eiloart wrote:

> This is one reason to support an IMAP extension.

There's no reason not to.  The important thing to realize at this stage 
is the basic principles an implementation of a "standard spam button" 
thing should support: multiple reporting mechanisms, specifiable 
destinations, and a couple flavours of content.

Discussions over whether there should be IMAP, POP, SMTP, NTP, DNS, 
HTTP, NNTP, or whatever mechanisms is largely irrelevant at this stage. 
  A recognition that there should be provision for more than one is the 
useful bit.  The important bit right now is the signalling and things 
like, who can specify, whether one can override, whether multiple 
destinations is desired.

 > If the communication is between the authenticated user and the
 > IMAP server, then there doesn't seem to be room for abuse of the
 > abuse reporting mechanism.

Given the rise of AUTH hijacking in current use for spamming, you have 
to pay attention even here, and I'm sure the miscreants will come up 
with something.  Senders would like to be able to specify.  Meaning that 
the local report destination has to be able to handle that forwarding. 
Meaning there are potential vulnerabilities.

Eg: scum spammer inserting instructions to forward complaints as a DOS 
to an innocent third party.