Re: [Asrg] Adding a spam button to MUAs

Steve Atkins <steve@blighty.com> Fri, 05 February 2010 19:29 UTC

Return-Path: <steve@blighty.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 8D3CE28C177 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:29:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.45
X-Spam-Level:
X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 D1EOg2AZmyRr for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:29:09 -0800 (PST)
Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 37C3F28C0E0 for <asrg@irtf.org>; Fri, 5 Feb 2010 11:29:09 -0800 (PST)
Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 2A4B64F856C for <asrg@irtf.org>; Fri, 5 Feb 2010 11:29:59 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <steve@blighty.com>
In-Reply-To: <4B6C6E56.5010802@nortel.com>
Date: Fri, 5 Feb 2010 11:29:59 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <9B9E89BC-32B9-41D2-B1EA-AA5C78FFBAFE@blighty.com>
References: <20100205151049.85259.qmail@simone.iecc.com> <Pine.GSO.4.64.1002051011310.28969@nber6.nber.org> <4B6C653C.7060807@nortel.com> <F20D7208-2839-4B53-ADC9-471D11880F70@blighty.com> <4B6C6E56.5010802@nortel.com>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
X-Mailer: Apple Mail (2.1077)
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 19:29:10 -0000

On Feb 5, 2010, at 11:15 AM, Chris Lewis wrote:

> Steve Atkins wrote:
> 
> Okay, but "arf" is so short ;-) And we have to get everybody else to use it.
> 
> "feedback" works too.
> 
>> The only setting that the MUA is likely to have access to is the name of the IMAP or POP3 server. As IMAP and POP3 are not name-based, the entry there could easily be domain.com, mail.domain.com, imap.domain.com or pop.domain.com or smtp.domain.com or even www.domain.com.
> 
> It has the default name used in inbound email, as well as (usually) an email address used as a userid.  Per delivery server.  It may even be able to see the rcpt to (or the MTA could "help".  Oh, never mind).

Lets look at a concrete example from my MUA

Account type: IMAP
Description: Fruitbat
Email address: steve@blighty.com, steve@wordtothewise.com, steve@word-to-the-wise.com, ...
Full Name: Steve Atkins
Incoming Mail Server: mail.wordtothewise.com
User name: steve
Password: *******
Outgoing Mail Server (SMTP): mail.wordtothewise.com

Of those, the only thing that's actually associated with the inbound mailbox is the incoming mail server.

In the mail itself, without parsing Received headers the only relevant headers are:

X-Original-To: steve@blighty.com
Delivered-To: steve@m.wordtothewise.com
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <4B6C7000.5060207@dcrocker.net>

So the only data I'd have to work with as a self-configuring plugin would be the IMAP server hostname, mail.wordtothewise.com.

> 
>> One option is to have the MUA "use some heuristic to find the 'domain' associated with that hostname", but past experience with SSP suggests that it makes people point and laugh at you and start mentioning things like imap.aardvark.us.com.
>> Another would be to prepend "feedback." to the imap server name - so do an MX lookup for "feedback.imap.domain.com" to discover whether it's to enable the TiS button. That'll either need a DNS record added for every possible name for the IMAP server, or accept that it won't autoconfigure unless the recipient uses the name for the IMAP server you're expecting, either of which seems reasonable.
>> (That doing MX lookups is not something that MUAs typically need code for, and that isn't supported by base API, is a minor issue but worth mentioning).
> 
> Agreed.  I suspect many MUAs are completely incapable of doing direct to MX, and don't do MX lookups.  See other suggestion, where I say "Use normal submit mechanism".

Yeah, the usual submit mechanism is the way to go for actually sending the reports.

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.

Cheers,
  Steve