Re: [Asrg] Consensus Call - submission via posting (was Re: Iteration #3)

"Andrew Richards" <ar-asrg@acrconsulting.co.uk> Mon, 08 February 2010 17:34 UTC

Return-Path: <ar-asrg@acrconsulting.co.uk>
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 2BB343A724D for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 09:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Level:
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311]
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 FmU4DNrSUio7 for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 09:34:40 -0800 (PST)
Received: from mx.nwdb.co.uk (arichards02.wiredworkplace.net [213.143.2.79]) by core3.amsl.com (Postfix) with SMTP id E0F3A3A690D for <asrg@irtf.org>; Mon, 8 Feb 2010 09:34:39 -0800 (PST)
Received: (qmail 8833 invoked by uid 0); 8 Feb 2010 17:35:38 -0000
Received: (ofmipd 82.38.187.212); 8 Feb 2010 17:35:16 -0000
Date: Mon, 08 Feb 2010 17:35:39 +0000
Message-Id: <201002081735.39674.ar-asrg@acrconsulting.co.uk>
From: Andrew Richards <ar-asrg@acrconsulting.co.uk>
To: dcrocker@bbiw.net, Anti-Spam Research Group - IRTF <asrg@irtf.org>
User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic-pae; KDE/4.3.2; i686; ; )
References: <4B6C6D35.1050101@nortel.com> <4B6DAD0C.3020109@nortel.com> <4B6DB6D1.5050805@dcrocker.net>
In-Reply-To: <4B6DB6D1.5050805@dcrocker.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Consensus Call - submission via posting (was Re: Iteration #3)
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:34:41 -0000

On Saturday 06 February 2010 18:37:05 Dave CROCKER wrote:
> ...
>       Reports should be submitted using a mechanisms that:
> 
>       [1]  Is the same as for submitting regular new mail, that is,
>  normal posting.  (Determination of the address to send to is a separate
>  issue.)
> 
>       [2]  Is specific to the mechanism for retrieving the message for
>  which a report is being submitted.  (The details of such mechanisms is
>  a separate issue.)

I prefer [2].

What bugs me about [1] is that the whole message is being re-sent, but we 
seem to have established that the only thing a spam button will be saying 
is "This is spam/unwanted", so sending a report including the original 
email for basically a single bit of information seems excessive.

If the originating MTA(s) can be persuaded to hold onto [a copy of] the 
original message for at least a few days the reporting MUA merely needs to 
tell its upstream MTA which message(s) are spam/unwanted by referring to 
their UIDLs or Message-IDs. In addition there seems to be a greater chance 
of inadvertent disclosure of information with [1] whereas with [2] we know 
the MTA has already seen the message.

I don't see POP3 as a problem with [2] as suggested elsewhere: It could be 
extended to include reporting a UIDL (or Message-ID) as spam/unwanted; 
unaltered implementations would simply answer 'unimplemented', which I 
don't see as a problem: If people like having a spam button they can 
persuade their POP3 provider to implement the server-side part of it or 
vote with their feet.

cheers,

Andrew.