Re: [Asrg] Adding a spam button to MUAs

Steve Atkins <> Wed, 03 February 2010 16:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E9BCE3A6C76 for <>; Wed, 3 Feb 2010 08:52:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 APvgxW2N4U4i for <>; Wed, 3 Feb 2010 08:52:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 242053A6986 for <>; Wed, 3 Feb 2010 08:52:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id DE5964F84DB for <>; Wed, 3 Feb 2010 08:52:51 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <>
In-Reply-To: <>
Date: Wed, 3 Feb 2010 08:52:51 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <>
To: Anti-Spam Research Group - IRTF <>
X-Mailer: Apple Mail (2.1077)
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:52:10 -0000

On Feb 3, 2010, at 8:25 AM, Chris Lewis wrote:

> 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.

That's all a bit "why go for a simple approach, when a complex one will work?", though.

> 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.

Anything that's done via the mailbox retrieval protocol is going to need to support at least POP3 andIMAP4, possibly others. That's already doubling the complexity. While IMAP could be handled via some "standard" mailbox naming, POP3 is going to require an out-of-band communication channel from MUA to mailbox provider, unless you're already doing something horrible like XTND XMIT. If the communication from mailbox provider to MUA needs to be in-band (as opposed to implicit or sent as part of the message payload) then that would probably require rewrites of the imap or pop3 server to support it. That's a whole lot of development effort.

It's also likely to require extensions to the protocol handler in the MUA. That means it most likely couldn't be implemented as a plugin, rather it would require changes to the MUA core code.

The original question was something like "how might an MUA notify the mailbox provider when the user hits the TiS button". This is, pretty much, a solved problem in specific cases, so the interesting question is how to do it such that most any client MUA can communicate with most any mailbox provider, while minimizing the amount o development work needed.

That suggests a lowest common denominator approach, rather than anything fancy. And there are just two thing every modern MUA has in common - that's the ability to submit mail via SMTP, and the ability to read and write 822+mime format messages.

(This all is predicated on supporting POP3, as there's lots of ways to do this via IMAP, but I think that's a given.)