Re: [Asrg] Adding a spam button to MUAs

John Levine <johnl@taugh.com> Fri, 05 February 2010 15:46 UTC

Return-Path: <johnl@iecc.com>
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 3B4763A6F19 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 07:46:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.051
X-Spam-Level:
X-Spam-Status: No, score=-19.051 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_HI=-8, 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 uTxGUOQSVrkY for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 07:46:07 -0800 (PST)
Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 089C83A6D91 for <asrg@irtf.org>; Fri, 5 Feb 2010 07:46:06 -0800 (PST)
Received: (qmail 59339 invoked from network); 5 Feb 2010 15:46:55 -0000
Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 5 Feb 2010 15:46:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1002; olt=johnl@user.iecc.com; bh=cAi/sawJ20WvhZBbl6K5nJWqSLYly0WmoI6zq8qjYPs=; b=1bstPLwbhz0YL1C3D0jsHSf8Dgrs9k4HclscgB1FArAqhM/958oYcKZo/n/WIJ5zyVRqVpX/hSwI9XMxgYrkg3zdFGCxB8EWvAk3Ju2XvO5FKNDmDbS2xZiV95wgRjD3TTS5lnctTwt4QujipLI1tcuX+qO5TYZbFW4fUl61e/o=
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1002; bh=cAi/sawJ20WvhZBbl6K5nJWqSLYly0WmoI6zq8qjYPs=; b=o6MR0txeJNsH3tWeosdobSzCF3qYbqrVXlZEoeNIoBGsL5SEONhhwQWuNjcb81WegU22aeyvntz4dllIW4tbRaIMIkG66xLtlN4BOzvaWmsE4fkamuUnXHXUdFCHMRrB+KZySMAaKHh5Vau1axEtTcW/GbnSdV1/3vzBuSXps80=
Date: 5 Feb 2010 15:46:55 -0000
Message-ID: <20100205154655.94051.qmail@simone.iecc.com>
From: John Levine <johnl@taugh.com>
To: asrg@irtf.org
In-Reply-To: <Pine.GSO.4.64.1002051011310.28969@nber6.nber.org>
Organization:
Cc:
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
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:46:08 -0000

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

I share your concern about demanding upgrades to large amounts of mail
software which is why I'm not thrilled about changes to IMAP and POP
protocols.  I also think it's pretty important that the reporting
process has to be opt-in.  That's why an extra field in the
Authentication-Results header is attractive, it's something that
delivering MTAs are somewhat likely to add as part of the spam
filtering process anyway, and doesn't require and changes to the
downstream POP or IMAP or whatever.

R's,
John