Re: [Asrg] Adding a spam button to MUAs

Steve Atkins <> Fri, 05 February 2010 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B59A13A6DFE for <>; Fri, 5 Feb 2010 12:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.449
X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.006, 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 2WdwTmqef15D for <>; Fri, 5 Feb 2010 12:07:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id F10C93A6DF6 for <>; Fri, 5 Feb 2010 12:07:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 984234F8200 for <>; Fri, 5 Feb 2010 12:08:24 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <>
In-Reply-To: <>
Date: Fri, 5 Feb 2010 12:08:24 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Anti-Spam Research Group - IRTF <>
X-Mailer: Apple Mail (2.1077)
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:07:33 -0000

On Feb 5, 2010, at 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>".


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

So an A record for to demonstrate existence, and an MX record for the same to actually control delivery.

So the MUA can lookup the A record for to enable the TiS button, and when the TiS button is pressed it just sends email, using it's normal submission server, to or something like that, and the smarthost delivers that just as it would any other email.

If the MUA checks for the A record when fetching mail, rather than when displaying it, it'll all work when I'm on a plane too. Yay for store-and-forward!