Re: [Asrg] Adding a spam button to MUAs

Daniel Feenberg <feenberg@nber.org> Fri, 05 February 2010 12:09 UTC

Return-Path: <feenberg@nber.org>
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 272D73A6BD1 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 04:09:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Level:
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, UNPARSEABLE_RELAY=0.001]
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 4Agxxl1ZLcqb for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 04:09:41 -0800 (PST)
Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 18D4F3A6BDA for <asrg@irtf.org>; Fri, 5 Feb 2010 04:09:40 -0800 (PST)
Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.3/8.13.8) with ESMTP id o15CAN4O013235 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 5 Feb 2010 07:10:24 -0500 (EST) (envelope-from feenberg@nber.org)
Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.8+Sun/8.12.10) with ESMTP id o15C98pq006889; Fri, 5 Feb 2010 07:09:08 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id o15C97Zw006886; Fri, 5 Feb 2010 07:09:08 -0500 (EST)
X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs
Date: Fri, 5 Feb 2010 07:09:05 -0500 (EST)
From: Daniel Feenberg <feenberg@nber.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <4B6B5F78.3070607@nortel.com>
Message-ID: <Pine.GSO.4.64.1002050659560.5587@nber6.nber.org>
References: <20100204232046.53178.qmail@simone.iecc.com> <4B6B5F78.3070607@nortel.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20100204 #3415487, check: 20100205 clean
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 12:09:42 -0000

On Thu, 4 Feb 2010, Chris Lewis wrote:

> John Levine wrote:
>>> In any case it hardly matters because POP3 and IMAP are completely 
>>> different
>>> protocols with different constituencies. You'd never have a standards 
>>> effort
>>> that lumps them together in a million years, and even if you did you'd do
>>> nothing more than needlessly confuse the programmers of their respective
>>> code bases.
>> 
>> Actually, we've seen a reasonable suggestion a few messages back that
>> would work equally well with POP and IMAP: extract a reporting address
>> from the message and send it an ARF report.  It has the admirable
>> characteristic of being completely agnostic about how the mail is
>> delivered, since there are plenty of delivery techniques other than
>> POP and IMAP, such as WebDAV, uucp (still handy for intermittent
>> connections), fetchmail, and just reading the local mailstore.
>
> If we want to sidestep the issue of how to deal with senders wanting their 
> FBLs, the very simplest method of all is to have the TiS button send an ARF 
> to a specific address, and let that address figure out everything else.
>
> I could live with that even in my odd-ball architecture (which probably 
> resembles other very large infrastructures).  I already do that (without the 
> ARF format), and the recipient address has to be manually configured in the 
> MUA.
>
> I'd only add that I'd prefer _not_ to have to have the user configure the MUA 
> where to send the ARFs to.  The receiving mail server inserts it.  Meaning 
> that the MUA has to be able to determine it's valid.
>

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.

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.

If someone already has the userid "arf", that is too bad.

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

> If we only support emailed ARFs, the only parameter you need is the address.
>
> This has the advantage of being able to work correctly if the MUA receives 
> email from several different infrastructures, even if some don't support 
> reporting.
>
> Even has the ability to work if the receiving mail system can't handle the 
> ARFs at all, just forward em off to a trusted 3rd party.
> _______________________________________________
> Asrg mailing list
> Asrg@irtf.org
> http://www.irtf.org/mailman/listinfo/asrg
>