Re: [Asrg] Adding a spam button to MUAs

"Andrew Richards" <> Wed, 09 December 2009 22:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02F933A699D for <>; Wed, 9 Dec 2009 14:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.383
X-Spam-Status: No, score=-0.383 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PX5QniC2gT7D for <>; Wed, 9 Dec 2009 14:05:59 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id A3D6E3A6808 for <>; Wed, 9 Dec 2009 14:05:58 -0800 (PST)
Received: (qmail 6621 invoked by uid 0); 9 Dec 2009 22:05:41 -0000
Received: (ofmipd; 9 Dec 2009 22:05:19 -0000
Date: 9 Dec 2009 22:05:42 +0000
Message-Id: <>
From: "Andrew Richards" <>
To: "Anti-Spam Research Group - IRTF" <>
User-Agent: KMail/1.11.2 (Linux/2.6.28-17-generic; KDE/4.2.2; i686; ; )
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan>
In-Reply-To: <alpine.BSF.2.00.0912082138050.20682@simone.lan>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 22:06:00 -0000

On Wednesday 09 December 2009 05:35:03 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.

When setting up mail server IMAP & POP3 settings there could be 'Spam 
reporting' options available - for IMAP this would presumably be the folder 
where junk is placed to be reported; for POP3 this might just be a checkbox to 
say that a JUNK command is implemented as John suggests.

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

An MTA providing a junk/spam reporting function might choose to keep [a copy 
of] all messages for at least a few days so that UIDLs refer to messages 
available to the MTA. This has the advantages,
 - The MTA wouldn't have to remove any headers added by the MUA
 - No significant bandwidth is required to communicate the UIDL (contrast
   this to the MUA having to send a message back to the MTA)

Perhaps MTAs that wish to provide spam reporting functionality should be 
required to keep [a copy of] messages for a few days, probably separate from 
the users' mailbox/folders view so that users/MTAs can still DELEte messages 

If a JUNK command comes in after the MTA's copy of the message has been 
deleted the command can just be ignored - most JUNK commands can be expected 
to be received within a few days of the user downloading the corresponding 
messages; or better still the MTA can inform the MUA whether it's been able to 
successfully find the corresponding message and report it / unsubscribe it etc.

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

I don't like this idea because of the waste of bandwidth (users may not 
appreciate sending back a large message if their upload bandwidth is low 
compared to their downstream - e.g. ADSL)

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