Re: [Asrg] MUA/Operator reporting address (was Re: Adding a spam button to MUAs)

"Chris Lewis" <> Fri, 05 February 2010 20:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B9E03A6CEC for <>; Fri, 5 Feb 2010 12:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.439
X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N0LZzPttJujV for <>; Fri, 5 Feb 2010 12:39:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 529603A68AC for <>; Fri, 5 Feb 2010 12:39:29 -0800 (PST)
Received: from ( []) by (Switch-2.2.6/Switch-2.2.0) with ESMTP id o15Ke2l15489; Fri, 5 Feb 2010 20:40:03 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 15:39:47 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 5 Feb 2010 15:39:46 -0500
Message-ID: <>
Date: Fri, 5 Feb 2010 15:39:34 -0500
From: "Chris Lewis" <>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20090812 Lightning/0.9 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To: "" <>, Anti-Spam Research Group - IRTF <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Feb 2010 20:39:47.0218 (UTC) FILETIME=[5B1FEF20:01CAA6A3]
Subject: Re: [Asrg] MUA/Operator reporting address (was Re: 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: Fri, 05 Feb 2010 20:39:30 -0000

Dave CROCKER wrote:
> On 2/5/2010 12:01 PM, Chris Lewis wrote:
>> Steve Atkins wrote:
>>> Of those, the only thing that's actually associated with the inbound
>>> mailbox is the incoming mail server.
>> As you suggest, key it to "feedback@feedback.<incoming server name>".
> This covers 3 specific choices, each of which ought to get a bit of discussion.
> 1. Mailbox name
> There is an official list of required/standard email addresses:
>     <>
> We should make this exercise be an extension to that.  Offhand, 'feedback' 
> strikes me as too generic, for what is actually a pretty specific function.
> The existing, relevant reserved mailbox string is 'abuse'.  Should this new one 
> be related to it?

That would be okay, but it shouldn't _be_ "abuse".  That's more for 
abuse originating locally, not that originating elsewhere.  We use 
"spam" for spam reporting ;-)

> 2. Sub-domain
> Why have a sub-domain?  And to the extent one is needed, why not use the 
> developing convention of an underscore name, such as _report.<domain>?

Sub-domain because presumably you have incoming mail server already, and 
you don't want to standardize on something that will collide with 
existing infrastructure conventions.  Even if it's mail related.

> The address to be used is really an 'attribute' of the main domain, and the 
> underscore convention has developed as a way of defining additional attributes 
> for a domain name.  In addition, the naming convention does not run the risk of 
> colliding with an existing use of sub-domains.

Problem with main domain is trying to figure out what it is, and it may 
not be the registered name. and may have 
entirely separate infrastructures even if you could derive "" 
from "".  So, it should at worst, be related to the 
naming of the infrastructure you actually use.

> 3. Domain.
> Clients currently have two domains to draw from, posting domain and pickup 
> domain.  Choosing incoming probably /is/ best, because that's the place that 
> handed the user the problem message and therefore it's the place that ought to 
> provide the information about where to report problems.
>>> The charm of using an MX record to configure this is that the MUA can
>>> do an MX lookup to know whether to show or hide the button. That's
>>> pretty clean, and if I were coding an MUA I'd be happy to do it that
>>> way, but it's not necessarily a _trivial_ thing to add to a codebase,
>>> especially via plugin, so it's worth considering.
>>  From the perspective of code base, checking for an A record for
>> "feedback.<incoming server name>" would be simpler. The MTA doesn't need
>> to use DNS to deliver, and you really don't want the MUA to be
>> establishing direct connections anyway. Fixed route to whereever in the
>> MTA.
> Just to check:  The choice between using an A or an MX is an optimization, 
> rather than strategic, yes?  That is, either is sufficient to the task, so a 
> debate is about better?

There are some specific technical advantages to an A for existance 
(enable TiS button), and MX for routing (where submission server sends 
it).  Doing it that way around minimizes extra work, eg: many MUAs might 
not _have_ MX lookup code, but you know they have to have A lookup, so 
"A" is more convenient for what the MUA needs to do (light up the TiS 
button).  The MX makes MTA routing work perfectly sanely.  The A record 
doesn't even have to point at anything useful, because the MUA doesn't 
have to go there (and may not be able to), just exist.