Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <clewis@nortel.com> Wed, 03 February 2010 22:30 UTC

Return-Path: <CLEWIS@nortel.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 5C0B73A65A6 for <asrg@core3.amsl.com>; Wed, 3 Feb 2010 14:30:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.469
X-Spam-Level:
X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 6b+vGxHgRvpw for <asrg@core3.amsl.com>; Wed, 3 Feb 2010 14:30:09 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2CB123A6811 for <asrg@irtf.org>; Wed, 3 Feb 2010 14:30:08 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o13MUm510732 for <asrg@irtf.org>; Wed, 3 Feb 2010 22:30:48 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Feb 2010 17:30:46 -0500
Received: from [47.129.150.21] (47.129.150.21) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 3 Feb 2010 17:30:45 -0500
Message-ID: <4B69F90D.90402@nortel.com>
Date: Wed, 3 Feb 2010 17:30:37 -0500
From: "Chris Lewis" <clewis@nortel.com>
Organization: Nortel
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20100201145903.30670.qmail@simone.iecc.com> <3741B85B916D847C703F2724@lewes.staff.uscs.susx.ac.uk> <A50C736E-EE14-4213-B99D-DD58C669FDAC@blighty.com> <100201092326.ZM5487@torch.brasslantern.com> <4B67ADC2.4080204@nortel.com> <1265090468.19504.22.camel@darkstar.netcore.co.in> <e0c581531002021629r1c54c2bdy8d550c410497f677@mail.gmail.com> <6ED765A6FA316CD5CB3ABAF9@lewes.staff.uscs.susx.ac.uk> <4B69A37E.3020803@nortel.com> <FC341DD0-D969-403B-A731-C496567A9BC1@blighty.com>
In-Reply-To: <FC341DD0-D969-403B-A731-C496567A9BC1@blighty.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 03 Feb 2010 22:30:46.0211 (UTC) FILETIME=[875E2130:01CAA520]
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, 03 Feb 2010 22:30:10 -0000

Steve Atkins wrote:
> On Feb 3, 2010, at 8:25 AM, Chris Lewis wrote:
> 
>> Ian Eiloart wrote:
>>
>>> This is one reason to support an IMAP extension.
>> There's no reason not to.  The important thing to realize at this stage is the basic principles an implementation of a "standard spam button" thing should support: multiple reporting mechanisms, specifiable destinations, and a couple flavours of content.
> 
> That's all a bit "why go for a simple approach, when a complex one will work?", though.

True to an extent, on the other hand, the alternative is an 
un-upgradeable spec that may be obsolete before it's ever used. There's 
no need to necessarily specify how each of the variations work nor even 
which ones are necessarily valid, just specify how the statements (of 
what, where, how) are made.  Then each of the "what, where, hows" can be 
independently specified as companion specs when people think they need 'em.

Kinda like the return codes of EHLO in ESMTP ;-)

At this point we need to be technology agnostic as much as possible, and 
specify what the thing actually does and how to express it header-wise 
(or whatever) in keeping with security, usefulness and flexibility.