Re: [Asrg] Adding a spam button to MUAs

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B44F928C1A8 for <>; Fri, 5 Feb 2010 12:01:12 -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 ttrigEziJxno for <>; Fri, 5 Feb 2010 12:01:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6A4CE28C202 for <>; Fri, 5 Feb 2010 12:01:06 -0800 (PST)
Received: from ( []) by (Switch-2.2.0/Switch-2.2.0) with ESMTP id o15K1s726558 for <>; Fri, 5 Feb 2010 20:01:54 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Feb 2010 15:01:54 -0500
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 8.1.340.0; Fri, 5 Feb 2010 15:01:53 -0500
Message-ID: <>
Date: Fri, 5 Feb 2010 15:01:41 -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:01:54.0297 (UTC) FILETIME=[105BB690:01CAA69E]
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: Fri, 05 Feb 2010 20:01:12 -0000

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

>> But a critical bit of UI design is that it should be clear to the user whether something will happen, or not. So for this to be workable the MUA needs to be able to configure itself to show or hide the TiS button (or grey it out, or whatever UI idiom you like).
> 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