Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <> Mon, 01 February 2010 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E86D73A6405 for <>; Mon, 1 Feb 2010 09:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.743
X-Spam-Status: No, score=-4.743 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6+CpYW6MqEfr for <>; Mon, 1 Feb 2010 09:08:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1A6FC3A695A for <>; Mon, 1 Feb 2010 09:08:36 -0800 (PST)
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by with ESMTPSA; Mon, 01 Feb 2010 18:09:10 +0100 id 00000000005DC033.000000004B670AB6.000009AA
Message-ID: <>
Date: Mon, 01 Feb 2010 18:09:10 +0100
From: Alessandro Vesely <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 01 Feb 2010 17:08:41 -0000

On 01/Feb/10 17:20, Chris Lewis wrote:
> Steve Atkins wrote:
>> On Feb 1, 2010, at 6:59 AM, John Levine wrote:
>>>> Except that that isn't, I presume, the way these buttons currently
>>>> work - except when somebody is subscribed to a feedback loop. It
>>>> seems over-complicated and inefficient (even with BURL) to send an
>>>> ARF to your own system admin, and rather more simple to just set a
>>>> flag or annotation on the IMAP server.

However, it's not trivial to timely interpret changes in the IMAP folders.

>>> You're right, for the minority of us who run IMAP. For everyone else
>>> who uses POP, mailing an ARF report back to the POP server may be the
>>> best we can do. The authserv-id from RFC 5451 isn't ideal to use as
>>> the mailing address since the RFC says quite clearly that it has to
>>> look like a FQDN but it doesn't actually have to be an FQDN.
>>> If we go down this route, we could probably add a flag to 5451 to
>>> say it's OK to send ARF reports.

I'd guess that hosts who don't support getting abuse reports can 
choose an authserv-id which is not a mail domain. At any rate, they 
will have to instruct their users on how to enable processing of that 
header field.

>> ... or put it in the the message, where there's one standard format
>> to deal with, rather than tying it to just one of the various ways
>> people retrieve messages. Most everyone already stashes an assortment
>> of metadata in the headers anyway.

Uh? The authserv-id from RFC 5451 is right there already...

> Which gives you the opportunity to do more complicated things, like if
> the IMAP/POP servers aren't the place to send the notification. In our
> case, they're not.

If using ARF, more complicated behavior might be noted in specific 
fields. In several cases --e.g. unsubscribe, FBL-- some kind of 
forwarding is required anyway. Changes will be easier to manage if the 
software is centralized at a few abuse@ handlers, than if complicated 
behavior is carried out by each client.

> A X- header that has machine-readable instructions on what the reader
> should do if you hit the TiS button.

A savvy client should seek user's consent anyway.

> I'd envisage emailing ARF or plain forwards or site-chosen identifiers
> to a specified place. Plus something non-SMTP.

Sticking to ARF seems smoother, from the server handler POV.