Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Fri, 29 January 2010 18:45 UTC

Return-Path: <vesely@tana.it>
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 7832E3A6932 for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 10:45:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.758
X-Spam-Level:
X-Spam-Status: No, score=-4.758 tagged_above=-999 required=5 tests=[AWL=-0.195, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, 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 YkJNd2G6ylVV for <asrg@core3.amsl.com>; Fri, 29 Jan 2010 10:45:09 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1E2CA3A67E5 for <asrg@irtf.org>; Fri, 29 Jan 2010 10:45:08 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 29 Jan 2010 19:45:29 +0100 id 00000000005DC043.000000004B632CC9.00000E22
Message-ID: <4B632CC9.6070809@tana.it>
Date: Fri, 29 Jan 2010 19:45:29 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100127172200.36250.qmail@simone.iecc.com> <BD52C76861B321AEE74E703A@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <BD52C76861B321AEE74E703A@lewes.staff.uscs.susx.ac.uk>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: Fri, 29 Jan 2010 18:45:11 -0000

On 28/Jan/10 11:46, Ian Eiloart wrote:
> --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.

I really would leave this bit out for the time being. Avoiding to 
upload the message is a minor optimization that can be carried out any 
time. (Compare it with saving sent mail by BCC rather than uploading 
the same message twice.)

IMHO it is more important to focus on _how_ and _where_, the answers 
being, respectively, ARF and abuse@<authserv-id>, where the latter is 
defined in http://tools.ietf.org/html/rfc5451#section-2.3 Note that 
users have to configure their clients specifying which authserv-id 
they trust for each account. This stone can kill both birds.

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

The IMAP UID is used to refer to a specific message (rfc5092), which 
is what could be used with BURL (rfc4468) to optimize reporting when 
the IMAP server can also be used as an MSA.