Re: [Asrg] Adding a spam button to MUAs

"Chris Lewis" <clewis@nortel.com> Tue, 02 February 2010 04:44 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 4B2153A69F7 for <asrg@core3.amsl.com>; Mon, 1 Feb 2010 20:44:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.406
X-Spam-Level:
X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.037, 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 7F7WLObXFCmL for <asrg@core3.amsl.com>; Mon, 1 Feb 2010 20:44:25 -0800 (PST)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 186F03A6A5C for <asrg@irtf.org>; Mon, 1 Feb 2010 20:44:24 -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 o124iub22516 for <asrg@irtf.org>; Tue, 2 Feb 2010 04:44:56 GMT
Received: from zrtphx5h0.corp.nortel.com ([47.140.202.65]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 1 Feb 2010 23:44:56 -0500
Received: from [47.130.65.86] (47.130.65.86) by zrtphx5h0.corp.nortel.com (47.140.202.65) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 1 Feb 2010 23:44:55 -0500
Message-ID: <4B67ADC2.4080204@nortel.com>
Date: Mon, 01 Feb 2010 23:44:50 -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>
In-Reply-To: <100201092326.ZM5487@torch.brasslantern.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Feb 2010 04:44:56.0164 (UTC) FILETIME=[77C19A40:01CAA3C2]
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: Tue, 02 Feb 2010 04:44:26 -0000

Bart Schaefer wrote:
> On Feb 1,  9:11am, Steve Atkins wrote:
> }
> } On Feb 1, 2010, at 8:57 AM, Ian Eiloart wrote:
> } 
> } > Does ARF allow richer expression than ANNOTATE?
> } 
> } Probably - it's basically a container format.
> } 
> } More importantly, perhaps, it would be easy to roll out on existing
> } installations with a trivial configuration change, rather than
> } requiring functionality in the mailstore that may not be there.

> Anything that's going to be added as metadata to the message header
> needs to be carefully specified so that a client that understands the
> format can reside behind a server that does not.  E.g., depending on
> where this metadata is added, one option might be to require a DKIM
> signature to cover it.

Consider the following off-the-cuff implementation possibility:

A header that has:

Name of server (or administrative unit (domain)) inserting the header.
What to send in report:
	ARF copy, or forward or selected header[s] or?
How to send report:
         email (including address), or some other protocol and
         destination.

Are we asking that these could be inserted at source (eg: on AOL 
outbounds)?  Or, receiving-end implementation?  Or both?

If receiver only, the receiver simply discards any previous ones and 
inserts their own.

As long as the client "knows" whether its front ends support this 
functionality (might be config value of administrative domain), and 
ignores them if it isn't, the security issues are fairly limited.

Still need DKIM?

If the sender is "permitted" to insert them, for them to mean much, you 
get into the same issues as end-to-end DKIM on email has.  You know that 
the signature verifies or not, but you still don't know whether you want 
to trust the information.

I think of this as more of a "receiver sets policy".  If we allow 
senders to insert them, we have to have a way for the receiver to assert 
overriding policy.  Eg: "everything but stuff I can tell is from AOL 
comes to me, and the AOL stuff can be sent as they request").  Either by 
inspecting and possibly altering/replacing the header in flight, or 
being able to get instructions on what to respect to the clients.  The 
latter might get rather nasty.

In any event, such things have to be thought out well in advance so that 
the clients do have a solid spec to work against, and the receivers know 
what they have to do too.