Re: [Asrg] Adding a spam button to MUAs

Daniel Feenberg <feenberg@nber.org> Fri, 05 February 2010 15:53 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 DE7C328C184 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 07:53:21 -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 8eSBQfummF0v for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 07:53:20 -0800 (PST)
Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 55F3728C171 for <asrg@irtf.org>; Fri, 5 Feb 2010 07:53:20 -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 o15Fs7DJ064864 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 5 Feb 2010 10:54:07 -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 o15FqpWK005435; Fri, 5 Feb 2010 10:52:51 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id o15FqpLK005432; Fri, 5 Feb 2010 10:52:51 -0500 (EST)
X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs
Date: Fri, 05 Feb 2010 10:52:51 -0500
From: Daniel Feenberg <feenberg@nber.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <20100205154655.94051.qmail@simone.iecc.com>
Message-ID: <Pine.GSO.4.64.1002051048210.4152@nber6.nber.org>
References: <20100205154655.94051.qmail@simone.iecc.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: 20100205 #3428449, 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 15:53:22 -0000

On Fri, 5 Feb 2010, John Levine wrote:

>>> Sorry, wouldn't work.  The name of the POP or IMAP server need not
>>> bear any relationship to any email address.  For example, on my
>>> system, the server is named imap.iecc.com (yes, even for POP, it
>>> deters the clueless) but there are not imap.iecc.com addresses at all.
>>
>> I don't understand why this is relevant. If the MTA operator doesn't want
>> to support this feature, he doesn't have to. But if he does wish to
>> support the feature he needs to supply an MX record or accept mail on the
>> POP or IMAP server. Is that such a great burden? Compared to the other
>> suggestions here?
>
> Honestly, none of us knows.  The name of the POP or IMAP server has
> never been intended as part of an e-mail address, so it's hard to
> predict what might break.  Overloading names tends to lead to
> surprising failures.  For example, my POP/IMAP server is also my
> SUBMIT server, and although it doesn't have an MX record, it does have
> an A record.  That means that with your proposal, if I did nothing and
> one of my users happened to have an MUA with a spam button, when he
> pressed it, it would connect to my SUBMIT server and send a message to
> the undeliverable address arf@imap.iecc.com, causing a baffling
> bounce.

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.

I take the concern is that over at AOL or GMAIL, they might want to have 
the ARF server different from the POP server, but not want to use an MX 
record to do so, perhaps because the POP server was also meant to receive 
other (non-arf) mail. It seems like a very thin reed for a protocol that 
is optional anyway.

Daniel Feenberg