Re: [Asrg] Generally workable ways of adding a spam button to MUAs

"Chris Lewis" <clewis@nortel.com> Mon, 08 February 2010 17:53 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 DDB3828C153 for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 09:53:45 -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 7lCP7tagReYy for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 09:53:44 -0800 (PST)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 738203A724D for <asrg@irtf.org>; Mon, 8 Feb 2010 09:53:44 -0800 (PST)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o18Hshr10562 for <asrg@irtf.org>; Mon, 8 Feb 2010 17:54:43 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Feb 2010 12:54:42 -0500
Received: from [47.130.64.86] (47.130.64.86) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 8 Feb 2010 12:54:42 -0500
Message-ID: <4B704FCF.7030406@nortel.com>
Date: Mon, 8 Feb 2010 12:54:23 -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: <20100205152046.87683.qmail@simone.iecc.com> <A57020F253FEFC9A8ED39F50@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <A57020F253FEFC9A8ED39F50@lewes.staff.uscs.susx.ac.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Feb 2010 17:54:42.0891 (UTC) FILETIME=[CAECD1B0:01CAA8E7]
Subject: Re: [Asrg] Generally workable ways of 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, 08 Feb 2010 17:53:46 -0000

Ian Eiloart wrote:
> 
> --On 5 February 2010 15:20:46 +0000 John Levine <johnl@taugh.com> wrote:
> 
>>>> Actually, we've seen a reasonable suggestion a few messages back that
>>>> would work equally well with POP and IMAP: extract a reporting address
>>>> from the message and send it an ARF report.
>>> Which is certainly not at all simpler than setting an IMAP flag on a
>>> message. And (if it's what the user desires) moving it out of the INBOX.
>> Can I ask people to stop making the newbie mistake of assuming that
>> all mail systems are, or should be, just like the mail system they
>> happen to use?
> 
> I'm not making that assumption.

By insisting on MDA-specific methods, it forces the same result as 
making the assumption that all the world is IMAP (+ POP or whatever 
other protocol we deign to notice).  It isn't.

> I'm simply claiming that the problem isn't 
> a single problem (1. "how to report junk messages"). It's two problems: "2. 
> how to report junk messages to an IMAP mailstore operator" and "3. how to 
> report junk messages to a POP mailstore operator".

Four: SMTP
Five: Webmail
Six: Microsoft RPC

etc.  We use all five.  Actually more, but, those are very much in the 
weeds.

There is no need to make it MDA specific, everything you can do with 
direct MDA feedback you can do with asynchronous MDA-independent methods.

Someone else seemed to imply that there's an inherent difference between 
"reporting for complaint handling" and "forwarding for filter tuning", 
and MDA-specific methods can only handle the latter.

Nothing could be further from the truth.  We do both, via non-MDA-based 
feedback.

While it might be a bit more convenient for some installations to tune 
_some_ kinds of filters directly with direct MDA submissions, in many if 
if not most cases it makes no difference because it isn't the MDA doing 
the filtering, and there's no reason that a non-MDA reporting 
destination can't adjust the MDA if it actually needs to.

Indeed, tuning MDAs directly (and independently) can introduce severe 
operational inconsistencies and manageability problems.

If we want acceptance of this, we need to make it as universal and 
technology independent as possible.

IOW: while MDA-specific mechanisms can sometimes make part of what 
you're doing a bit simpler, there's nothing that MDA-specific can do 
that MDA-independent can't, and MDA-independent is vastly more 
universally applicable.  Especially in mixed environments.