Re: [Asrg] Adding a spam button to MUAs

Ian Eiloart <iane@sussex.ac.uk> Wed, 09 December 2009 12:07 UTC

Return-Path: <iane@sussex.ac.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 EE16C3A68A5 for <asrg@core3.amsl.com>; Wed, 9 Dec 2009 04:07:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.445
X-Spam-Level:
X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 xZfFVn3VchiP for <asrg@core3.amsl.com>; Wed, 9 Dec 2009 04:07:13 -0800 (PST)
Received: from lynndie.uscs.susx.ac.uk (lynndie.uscs.susx.ac.uk [139.184.14.87]) by core3.amsl.com (Postfix) with ESMTP id A609F3A672F for <asrg@irtf.org>; Wed, 9 Dec 2009 04:07:13 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:64702) by lynndie.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KUDWCK-00011L-3K for asrg@irtf.org; Wed, 09 Dec 2009 12:07:32 +0000
Date: Wed, 09 Dec 2009 12:06:48 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <A08B931234D3D5E830D4C1D3@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <alpine.BSF.2.00.0912082138050.20682@simone.lan>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan>
Originator-Info: login-token=Mulberry:01gkrjOeurUZ7Dtzeb7nD1v1as6MIEk+Vw97U=; token_authority=support@its.sussex.ac.uk
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
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 12:07:15 -0000

--On 9 December 2009 00:35:03 -0500 "John R. Levine" <johnl@iecc.com> 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?

...
>>  For IMAP
>> accounts, a simple approach is to have an IMAP spam folder, and move the
>> message there.


Apple Mail already has a "Junk/Not Junk" ("In/désirable","No 
deseado/Conservar", etc) button. It uses it to feed it's internal content 
filter. When enabled, the action taken when spam is detected can be (a) 
mark the mail as spam (it appears brown in the list) or (b) file into a 
Junk mailbox (which can be any mailbox designated for the purpose), or (c) 
custom actions which include redirecting (eg to a spamcop address) or 
running an AppleScript.

On an IMAP server, it would probably be better to file the message into a 
designated junk mailbox, and have some process on the server take whatever 
action the service provider thought reasonable. The only new thing required 
here is a way of communicating either (i) to the user; which mailbox should 
be used as for junk, or (ii) to the server; which mailbox I'm actually 
using for junk.

The latter is probably the more principled approach, especially given 
language concerns; my server is at a University with a high proportion of 
international students! Perhaps some RFC5464 METADATA attached to the 
mailbox could be used. It would require a new entry at 
<http://www.iana.org/assignments/imap-metadata/imap-metadata.xhtml>

A more flexible approach would be the definition of a new standard IMAP 
flag: \Junk or similar. That would permit GMail style monolithic mailboxes, 
and even use of multiple mailboxes for junk (cf Twitter's "Block" and 
"Report" buttons).

So, the user might see a "junk" mailbox, but the client would need to flag 
every message that was filed in there. It might even be sensible to define 
a \Notjunk flag for training purposes, and you might want to do something 
different with user-designated junk than with automatically filed junk 
messages, so that might require an additional flag, say \Userjunk or 
\Autojunk in order to make the distinction. IANA don't seem to maintain a 
list of flags, so this might require a change to the RFC, or a new 
extension.


>
> Any bright ideas?  Is there a way to make this work with POP that isn't
> an utter kludge?

No ideas here, I'm afraid. This is the sort of thing that stops us offering 
POP to users.

> R's,
> John
> _______________________________________________
> Asrg mailing list
> Asrg@irtf.org
> http://www.irtf.org/mailman/listinfo/asrg



-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/