Re: [Asrg] Adding a spam button to MUAs

Alessandro Vesely <vesely@tana.it> Mon, 01 February 2010 17:08 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 E86D73A6405 for <asrg@core3.amsl.com>; Mon, 1 Feb 2010 09:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.743
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+CpYW6MqEfr for <asrg@core3.amsl.com>; Mon, 1 Feb 2010 09:08:40 -0800 (PST)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1A6FC3A695A for <asrg@irtf.org>; Mon, 1 Feb 2010 09:08:36 -0800 (PST)
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 01 Feb 2010 18:09:10 +0100 id 00000000005DC033.000000004B670AB6.000009AA
Message-ID: <4B670AB6.6050907@tana.it>
Date: Mon, 01 Feb 2010 18:09:10 +0100
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100201145903.30670.qmail@simone.iecc.com> <C255A5EA-CECD-460B-B54B-A115D2C0FA6A@blighty.com> <4B66FF5D.6040008@nortel.com>
In-Reply-To: <4B66FF5D.6040008@nortel.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: 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.