Re: [Asrg] Adding a spam button to MUAs

Ian Eiloart <> Mon, 08 February 2010 11:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C237B3A7063 for <>; Mon, 8 Feb 2010 03:42:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.453
X-Spam-Status: No, score=-2.453 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Peymg1KYY5lq for <>; Mon, 8 Feb 2010 03:42:17 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6A5E43A69B6 for <>; Mon, 8 Feb 2010 03:42:16 -0800 (PST)
Received: from ([]:64420) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KXITVT-000LFW-NN for; Mon, 08 Feb 2010 11:43:05 +0000
Date: Mon, 08 Feb 2010 11:43:05 +0000
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
Originator-Info: login-token=Mulberry:01sHFD6hnSsU/x3pdMHJcj5rZdFulkRBOXJdw=;
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] Adding a spam button to MUAs
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Feb 2010 11:42:18 -0000

--On 5 February 2010 10:52:51 -0500 Daniel Feenberg <> 

> 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 (yes, even for POP, it
>>>> deters the clueless) but there are not 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, 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.

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. "" isn't 
an email domain, but it might be one day. "" 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 taken. Clearly there's a possibility for an untaken address to be 
advertised in DNS, or as a property of the server in the POP3 or IMAP 
protocols. IMAP has a suitable extension already, but a special TXT record 
in the DNS would be the most likely option. But would that be advertised by 
the DOMAIN operator, or by the server operator. They're the same (the 
University) for my work domain, but different (me or Gmail) for my personal 

> 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
> _______________________________________________
> Asrg mailing list

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see