Re: [Asrg] Adding a spam button to MUAs

Steve Atkins <> Wed, 09 December 2009 06:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D49CF3A6ACD for <>; Tue, 8 Dec 2009 22:01:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.843
X-Spam-Status: No, score=-5.843 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7GcTRfHDBAxX for <>; Tue, 8 Dec 2009 22:01:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8DEE43A6AC0 for <>; Tue, 8 Dec 2009 22:01:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5632C80A36 for <>; Tue, 8 Dec 2009 22:00:51 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <>
In-Reply-To: <alpine.BSF.2.00.0912082138050.20682@simone.lan>
Date: Tue, 8 Dec 2009 22:00:50 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan>
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, 09 Dec 2009 06:01:04 -0000

On Dec 8, 2009, at 9:35 PM, John R. Levine wrote:

> Most web mail systems have a spam or junk button that lets a user report unwanted mail to his ISP.  The ISP does whatever it does, typically tune their spam filters, and perhaps send a feedback report if the message is from someone with whom they have an FBL agreement.
> Lots of us don't use web mail.  We use POP or IMAP to pick up our mail, and SUMBIT to send it.  How would we add a spam button in our MUAs work?
> An obvious approach would be to pack up the message in an ARF report and mail it somewhere.  I don't think that would work, because MUAs these days can handle multiple inbound and outbound accounts, with the various accounts only loosely connected.  I have users who pick up their mail here, but send via their ISP's mail server and vice versa.  If you were to send the report via SMTP you might well send it to someone who'd never seen the message before.
> So the report needs to be tied to the inbound account.  For IMAP accounts, a simple approach is to have an IMAP spam folder, and move the message there.  AOL does this in their IMAP access, so I suppose that makes it a de-facto standard.

It's also already supported by some MUAs. for one. Sorta.

>  POP is harder, since there's nothing I can see that would obviously do the trick.  If you could assume that the message was still on the server, you could have a JUNK command that provided the UIDL of the message to report, but in typical POP setups, the messages are downloaded and deleted from the server before the user sees them.  The alternative is to add a command to upload the junk message, e.g.
>  +OK send the message
> blah blah copy of downloaded message blah blah
> .
>  +OK junk reported
> That's workable, although it's slow since it has to upload the entire message, and it may be hard for MUAs to implement since they often add annotations to the downloaded messages that would confuse the server if handed back.
> Yet another possibility would be a command for the POP server that provides an address to which to the MUA can send an ARF report, keeping in mind that the report may take a roundabout route if the MUA is set up to use someone else's SUBMIT server.  The address would presumably be obscure and time limited, with the user's mailbox somehow encoded into it, so that the server can recognize the report when it arrives, and to limit the chances of random spam that happens to arrive at the reporting addresses being misinterpreted as a junk report.
> Any bright ideas?  Is there a way to make this work with POP that isn't an utter kludge?

The general purpose way would be for the receiving MX to embed a reporting address in a message header such that the MUA would then forward the message to when the user hit the button. The only functionality it requires from the MUA is the ability to send email, which almost all MUAs already support.

A small amount of cryptography can make that immune against most failure modes.

The only obvious flaw is that if the MX doesn't support whatever header is added it would be possible for the original sender to add that header to the mail they send, meaning that a sender can have recipients send spam reports from MX operators that don't support the protocol sent directly to them, rather than to the MX operator.

That's not actually a flaw, I don't believe. Rather it's a fairly significant advantage, in that it allows FBL consumers who are sending email to opt-in to an ad-hoc feedback loop from their recipients. Yet it also allows MX operators to override that by removing the header, or by replacing it with their own FBL reporting address instead - without the MUA needing any special knowledge, nor more than a few tens of lines of additional code to support.

It'd mostly be a slight variant on the List-Unsubscribe: header.