Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Wed, 09 December 2009 11:33 UTC

Return-Path: <vesely@tana.it>
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 07DDB28C113 for <asrg@core3.amsl.com>; Wed, 9 Dec 2009 03:33:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.341
X-Spam-Level:
X-Spam-Status: No, score=-4.341 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_43=0.6, 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 ox438+jNqxaQ for <asrg@core3.amsl.com>; Wed, 9 Dec 2009 03:33:04 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id EFAC13A69E3 for <asrg@irtf.org>; Wed, 9 Dec 2009 03:33:03 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 09 Dec 2009 12:32:50 +0100 id 00000000005DC02F.000000004B1F8AE2.000020B7
Message-ID: <4B1F8AE1.1070500@tana.it>
Date: Wed, 09 Dec 2009 12:32:49 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <alpine.BSF.2.00.0912082138050.20682@simone.lan> <F15BCC89-676C-4A15-A6DE-55A982598657@blighty.com>
In-Reply-To: <F15BCC89-676C-4A15-A6DE-55A982598657@blighty.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: Wed, 09 Dec 2009 11:33:05 -0000

Steve Atkins wrote:
> On Dec 8, 2009, at 9:35 PM, John R. Levine wrote:
>> MUAs these days can handle multiple inbound and outbound accounts, with the various accounts only loosely connected.  I have users who pick up their mail here, but send via their ISP's mail server and vice versa.  If you were to send the report via SMTP you might well send it to someone who'd never seen the message before.
>> 
>> So the report needs to be tied to the inbound account.  For IMAP accounts, a simple approach is to have an IMAP spam folder, and move the message there.  AOL does this in their IMAP access, so I suppose that makes it a de-facto standard.
> 
> It's also already supported by some MUAs. Mail.app for one. Sorta.

If a server fetches mail from remote IMAP or POP accounts, it has to 
annotate those messages in order to recognize them and route them to 
the corresponding abuse-box. This may require to introduce a new (not 
necessarily standard) header field.

> The general purpose way would be for the receiving MX to embed a reporting address in a message header such that the MUA would then forward the message to when the user hit the button. The only functionality it requires from the MUA is the ability to send email, which almost all MUAs already support.

We may reuse the authserv-id's from Authentication-Results header 
fields that the user trusts. This method implies the MUA has validated 
them, e.g. against the Received fields, and is thus preferable than 
using, say, Delivered-To. It provides for sending a report to multiple 
places, unlike the IMAP folder method.

Once the MUA knows which domain(s) take the responsibility of 
delivering a given message, it would be advisable to lookup an address 
list on the DNS and only resort to prepending "abuse@" if no record is 
found. This additional level of indirection brings a twofold 
advantage: on the one hand the MX has a chance to use a different 
address, e.g. abuse-to-be-forwarded@example.com; on the other hand, a 
third party can monitor abuse reports even if example.com is also the 
sending domain. To wit

  _abuse IN TXT "abuse-tbf@example.com,abuse-D27@certifier.example"

Example.com should do similar lookups when it forwards the report to 
the sending domain, eliding duplicates. Certifier.example, as part of 
its activity, should check that its agreed-upon addresses are present 
in the records of its certified domains.

Alternatively, synthesizing addresses from VBR-Info header fields may 
result in a similar set of recipients. However, separate validation 
would be needed to avoid sending the report to untrusted senders.