Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Fri, 05 February 2010 15:14 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 988F33A6A88 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 07:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.626
X-Spam-Level:
X-Spam-Status: No, score=-4.626 tagged_above=-999 required=5 tests=[AWL=-0.063, 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 SOshX9C5Tnt5 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 07:14:19 -0800 (PST)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 49AF53A6A6D for <asrg@irtf.org>; Fri, 5 Feb 2010 07:14:19 -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, 05 Feb 2010 16:15:09 +0100 id 00000000005DC031.000000004B6C35FD.000013AE
Message-ID: <4B6C35FC.9080306@tana.it>
Date: Fri, 05 Feb 2010 16:15:08 +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: <20100204232046.53178.qmail@simone.iecc.com> <4B6B5F78.3070607@nortel.com> <Pine.GSO.4.64.1002050659560.5587@nber6.nber.org>
In-Reply-To: <Pine.GSO.4.64.1002050659560.5587@nber6.nber.org>
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, 05 Feb 2010 15:14:20 -0000

On 05/Feb/10 13:09, Daniel Feenberg wrote:
> I haven't been following this thread very closely, but why not just
> establish a standard role account on the MUAs designated POP or IMAP
> server? Such as arf@pop.example.com? It effectively "preconfigures" the
> MUA since "arf" is standard and "example.com" is already known to the
> MUA. The less configuration the better, I think.

"Abuse", which is what the "a" in ARF stands for, has the advantage of 
being already set aside for this purpose by RFC 2142. The "pop." part 
is more of an hindrance in this case.

> I reject arguments that "arf" is English, and that non-english speakers
> need an address consistent with their native tongue - partly because
> users won't need to do the configuration themselves, partly because
> "arf" isn't English, and partly because the argument is just too silly
> anyway. People learn a few words of Italian if they want to play music,
> and a few words of French if they want to cook, they can learn a few
> words of English if they want to compute. I note that the French
> language standard for Fortran-66 was not widespread, even in France.

+1! As a side note, also standard IMAP folders names should be in 
English (possibly translated on the fly) otherwise an IMAP client's 
behavior would be incompatible with that of its translations.

>> I think this is important because many MUAs receive email from
>> multiple infrastructures, each potentially with their own policies.
>
> The MUA could keep track of the ARF server associated with the current
> POP/IMAP server.

It requires more development on MUA, and wouldn't work for a local 
server fed via fetchmail, that various Linux laptops sport.

However, a correct implementation of the Authentication-Results 
proposal should refuse to report as spam a message that had been 
manually moved from one account's mailbox to another, unless the user 
had thoughtlessly enabled the relevant authserv-id for the wrong mailbox.