Re: [Asrg] Adding a spam button to MUAs

"Andrew Richards" <ar-asrg@acrconsulting.co.uk> Wed, 09 December 2009 22:06 UTC

Return-Path: <ar-asrg@acrconsulting.co.uk>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F933A699D for <asrg@core3.amsl.com>; Wed, 9 Dec 2009 14:06:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.383
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PX5QniC2gT7D for <asrg@core3.amsl.com>; Wed, 9 Dec 2009 14:05:59 -0800 (PST)
Received: from mx.nwdb.co.uk (arichards02.wiredworkplace.net [213.143.2.79]) by core3.amsl.com (Postfix) with SMTP id A3D6E3A6808 for <asrg@irtf.org>; 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 82.38.187.212); 9 Dec 2009 22:05:19 -0000
Date: Wed, 09 Dec 2009 22:05:42 +0000
Message-Id: <200912092205.43335.ar-asrg@acrconsulting.co.uk>
From: Andrew Richards <ar-asrg@acrconsulting.co.uk>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
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-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=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 
etc.

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.
>
> JUNK
>    +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?

cheers,

Andrew.