Re: [Asrg] Adding a spam button to MUAs

Daniel Feenberg <feenberg@nber.org> Mon, 08 February 2010 12:49 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 878743A71E1 for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 04:49:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.291
X-Spam-Level:
X-Spam-Status: No, score=-7.291 tagged_above=-999 required=5 tests=[AWL=1.151, BAYES_00=-2.599, GB_I_LETTER=-2, 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 aq5kSXQZbfMK for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 04:49:54 -0800 (PST)
Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 5794C3A6D69 for <asrg@irtf.org>; Mon, 8 Feb 2010 04:49:54 -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 o18CopO8011115 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 8 Feb 2010 07:50:51 -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 o18CnUOf020515; Mon, 8 Feb 2010 07:49:30 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id o18CnUwf020512; Mon, 8 Feb 2010 07:49:30 -0500 (EST)
X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs
Date: Mon, 8 Feb 2010 07:49:26 -0500 (EST)
From: Daniel Feenberg <feenberg@nber.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <86E6B4F578AB51F17FC7A544@lewes.staff.uscs.susx.ac.uk>
Message-ID: <Pine.GSO.4.64.1002080735160.17361@nber6.nber.org>
References: <20100205154655.94051.qmail@simone.iecc.com> <Pine.GSO.4.64.1002051048210.4152@nber6.nber.org> <86E6B4F578AB51F17FC7A544@lewes.staff.uscs.susx.ac.uk>
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: 20100207 #3447574, check: 20100208 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: Mon, 08 Feb 2010 12:49:55 -0000

On Mon, 8 Feb 2010, Ian Eiloart wrote:

>
>
> --On 5 February 2010 10:52:51 -0500 Daniel Feenberg <feenberg@nber.org> 
> wrote:
>
>> 
>> 
>> On Fri, 5 Feb 2010, John Levine wrote:
>> 
>> 
>> This is just a general argument against all role accounts, including
>> postmaster, abuse, webmaster, etc. It doesn't balance the costs and
>> benefits, just notes a possible cost as though that was sufficient to
>> dismiss it.
>
> No, the argument is nothing to do with the left hand side of the address, 
> it's to do with the right hand side of the address. "imap.iecc.com" isn't an 
> email domain, but it might be one day. "imap.sussex.ac.uk" is not an email 
> domain, and it never will be.
>
> In the case where the imap server host name does happen to be an email 
> domain, there's a potential name space conflict. ARF@... may well already be

"Cnflict, ARF@" is the left hand side of the address. If imap.iecc.com 
becomes an email address, then it would be a mistake to assign a user the 
username of "arf".

If a role account is assigned to arf@poporimapserver.example.com then it 
is a problem if that address is already assigned to a user. It isn't a 
problem with no solution, though. Simply make sure that the RHS of the 
address is different from the already assigned address. This is almost 
always going to be the case for large providers, since machines for pop 
and imap service are distinct from email domain names. If they do not, it
is simple enough to arrange DNS to make that happen, without changing any 
hardware.

Perhaps another character string would lessen the objection on this point. 
The role account could be "arf-submission", although the anti-English 
crowd will complain. There is room for creativity.

Note that when I say "pop_or_imap" it doesn't really have to be restricted 
to those protocols. The MUA can use the hostname for the system providing 
incoming mail, without caring what protocol is actually used, nor is there 
any need for the letters "pop" or "imap" to be requed to be in the name. 
The TO: address ued for the ARF is simply the role account on the system 
providing mail, that will use it to tune content or other spam filters.


Daniel Feenberg