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

"Andrew Richards" <ar-asrg@acrconsulting.co.uk> Tue, 09 February 2010 17:33 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 B298C28C1FE for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 09:33:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.522
X-Spam-Level:
X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=0.017, 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 VD8zLkS5p+qN for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 09:33:15 -0800 (PST)
Received: from mx.nwdb.co.uk (arichards02.wiredworkplace.net [213.143.2.79]) by core3.amsl.com (Postfix) with SMTP id 579D328C159 for <asrg@irtf.org>; Tue, 9 Feb 2010 09:33:14 -0800 (PST)
Received: (qmail 3325 invoked by uid 0); 9 Feb 2010 17:34:17 -0000
Received: (ofmipd 82.38.187.212); 9 Feb 2010 17:33:55 -0000
Date: Tue, 09 Feb 2010 17:34:18 +0000
Message-Id: <201002091734.18678.ar-asrg@acrconsulting.co.uk>
From: Andrew Richards <ar-asrg@acrconsulting.co.uk>
To: 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> <4B6DB6D1.5050805@dcrocker.net> <201002081735.39674.ar-asrg@acrconsulting.co.uk>
In-Reply-To: <201002081735.39674.ar-asrg@acrconsulting.co.uk>
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: Tue, 09 Feb 2010 17:33:16 -0000

On Monday 08 February 2010 17:35:39 I wrote:
> 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.

A further thought: If MUAs use the UIDL / MessageID of the TiS message to 
communicate the message's spam/unwanted status there's not the issue of 
poisoning to worry about, whereas with SMTP/ARF there is the potential for 
malicious (false) ARF reports to be sent perhaps with the intent of 
degrading ("poisoning") a competitor's email reputation.

I expect this can be addressed in the ARF model (e.g. using some form of 
cookie mechanism) (maybe that's already been covered), but I mention it as 
a plus point for model [2].

cheers,

Andrew.