Re: [Asrg] Adding a spam button to MUAs

Ian Eiloart <iane@sussex.ac.uk> Thu, 28 January 2010 10:46 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 CD5833A6858 for <asrg@core3.amsl.com>; Thu, 28 Jan 2010 02:46:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.443
X-Spam-Level:
X-Spam-Status: No, score=-2.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 9oJ8T3FEM89D for <asrg@core3.amsl.com>; Thu, 28 Jan 2010 02:46:26 -0800 (PST)
Received: from karpinski.uscs.susx.ac.uk (karpinski.uscs.susx.ac.uk [139.184.14.85]) by core3.amsl.com (Postfix) with ESMTP id 5B70C3A676A for <asrg@irtf.org>; Thu, 28 Jan 2010 02:46:24 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:51271) by karpinski.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KWYDXS-0004EM-HS for asrg@irtf.org; Thu, 28 Jan 2010 10:46:40 +0000
Date: Thu, 28 Jan 2010 10:46:40 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <BD52C76861B321AEE74E703A@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <20100127172200.36250.qmail@simone.iecc.com>
References: <20100127172200.36250.qmail@simone.iecc.com>
Originator-Info: login-token=Mulberry:01dTCMft6R+uO2neDg4Vbopf/x26it2NhW6ps=; 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=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: Thu, 28 Jan 2010 10:46:28 -0000

--On 27 January 2010 17:22:00 +0000 John Levine <johnl@taugh.com> wrote:

>
> All they need to do is somehow send the message, or a pointer to a stored
> copy of the message, back to the user's own mail system.  The tricky bit
> is that MUAs have separate configs for inbound and outbound mail, so you
> can't just send the message via the outbound channel or you may be sending
> it to someone who's never seen it before.  For IMAP you could either
> have a special folder (what AOL does with its IMAP interface) or a new
> flag, for POP you'd have to invent a crock of some sort.

POP isn't really susceptible to simple solutions, as you say, so let's 
focus on IMAP.

There seem to be four options, to me:

(a) define a new flag per message,
(b) define an ANNOTATE annotation per message,
    <http://tools.ietf.org/html/rfc5257#section-3.1>
(c) define an METADATA annotation on a mailbox,
    <http://tools.ietf.org/html/rfc5464>
(d) do something adhoc with mailboxes as is done for "spam" , "sent 
messages", "trash" and the like.

Are there any other possibilities?

(d) is the closest example that we have. It's used by the service provider 
to communication information about spam status to the user. Of course, that 
suggests a fifth option - rewriting the subject header (but I almost wish I 
hadn't thought of that!). I can't think of examples where flags or 
annotations are set IN ORDER to facilitate communication between user and 
provider.

My preferred option would be (b) because (i) it's more flexible than a flag 
(eg, it *could* be used to distinguish between 'block' and 'report' 
requests if both the user and the admin desire) (ii) it preserves the 
information about location of the message, which makes "undo" easier than 
moving the message into a different mailbox, (iii) ANNOTATE has 
experimental RFC status, whereas ANNOTATEMORE is

The drawback of (b) is that it creates a client side user interface 
problem. Presumably the user doesn't want the inbox full of messages that 
have been reported. There needs to be a way for the message to be preserved 
for inspection by the admin, but hidden from (yet findable by) the user.

If defining new annotations, it might be useful to define them for other 
special maiboxes, too.

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