Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <clewis@nortel.com> Fri, 05 February 2010 00:00 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 BBABF28C168 for <asrg@core3.amsl.com>; Thu, 4 Feb 2010 16:00:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.418
X-Spam-Level:
X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.025, 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 cSUHTrsmWiRf for <asrg@core3.amsl.com>; Thu, 4 Feb 2010 16:00:29 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 97EAC3A6834 for <asrg@irtf.org>; Thu, 4 Feb 2010 16:00:28 -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 o1501AK05885 for <asrg@irtf.org>; Fri, 5 Feb 2010 00:01:11 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Feb 2010 19:00:03 -0500
Received: from [47.130.65.61] (47.130.65.61) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 4 Feb 2010 19:00:02 -0500
Message-ID: <4B6B5F78.3070607@nortel.com>
Date: Thu, 4 Feb 2010 18:59:52 -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: <20100204232046.53178.qmail@simone.iecc.com>
In-Reply-To: <20100204232046.53178.qmail@simone.iecc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Feb 2010 00:00:03.0269 (UTC) FILETIME=[2AD60F50:01CAA5F6]
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: Fri, 05 Feb 2010 00:00:29 -0000

John Levine wrote:
>> In any case it hardly matters because POP3 and IMAP are completely different
>> protocols with different constituencies. You'd never have a standards effort
>> that lumps them together in a million years, and even if you did you'd do
>> nothing more than needlessly confuse the programmers of their respective
>> code bases.
> 
> 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.  It has the admirable
> characteristic of being completely agnostic about how the mail is
> delivered, since there are plenty of delivery techniques other than
> POP and IMAP, such as WebDAV, uucp (still handy for intermittent
> connections), fetchmail, and just reading the local mailstore.

If we want to sidestep the issue of how to deal with senders wanting 
their FBLs, the very simplest method of all is to have the TiS button 
send an ARF to a specific address, and let that address figure out 
everything else.

I could live with that even in my odd-ball architecture (which probably 
resembles other very large infrastructures).  I already do that (without 
the ARF format), and the recipient address has to be manually configured 
in the MUA.

I'd only add that I'd prefer _not_ to have to have the user configure 
the MUA where to send the ARFs to.  The receiving mail server inserts 
it.  Meaning that the MUA has to be able to determine it's valid.

I think this is important because many MUAs receive email from multiple 
infrastructures, each potentially with their own policies.

If we only support emailed ARFs, the only parameter you need is the address.

This has the advantage of being able to work correctly if the MUA 
receives email from several different infrastructures, even if some 
don't support reporting.

Even has the ability to work if the receiving mail system can't handle 
the ARFs at all, just forward em off to a trusted 3rd party.