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

"Andrew Richards" <ar-asrg@acrconsulting.co.uk> Tue, 09 February 2010 13:30 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 711E43A7087 for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 05:30:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.517
X-Spam-Level:
X-Spam-Status: No, score=-0.517 tagged_above=-999 required=5 tests=[AWL=0.022, 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 GIQRMPUsP2XQ for <asrg@core3.amsl.com>; Tue, 9 Feb 2010 05:30:08 -0800 (PST)
Received: from mx.nwdb.co.uk (arichards02.wiredworkplace.net [213.143.2.79]) by core3.amsl.com (Postfix) with SMTP id EDE743A6D4A for <asrg@irtf.org>; Tue, 9 Feb 2010 05:30:07 -0800 (PST)
Received: (qmail 24404 invoked by uid 0); 9 Feb 2010 13:31:12 -0000
Received: (ofmipd 82.38.187.212); 9 Feb 2010 13:30:50 -0000
Date: 9 Feb 2010 13:31:12 +0000
Message-Id: <201002091331.13013.ar-asrg@acrconsulting.co.uk>
From: "Andrew Richards" <ar-asrg@acrconsulting.co.uk>
To: "Dave CROCKER" <dcrocker@bbiw.net>
User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic-pae; KDE/4.3.2; i686; ; )
References: <4B6C6D35.1050101@nortel.com> <201002082056.23128.ar-asrg@acrconsulting.co.uk> <4B707D33.1060608@bbiw.net>
In-Reply-To: <4B707D33.1060608@bbiw.net>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Cc: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Subject: Re: [Asrg] who has the message (was Re: 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 13:30:09 -0000

On Monday 08 February 2010 21:08:03 Dave CROCKER wrote:
> On 2/8/2010 12:56 PM, Andrew Richards wrote:
> >> That creates a massive barrier to adoption.  Huge implementation
> >>   overhead.
> >
> > However TiS is implemented will require implementation work on the
> > server- side, so I'm not sure that [2] is so different from [1] in
> > this respect.
> 
> The nature and amount of change on the server sides depends on quite a
>  few things.
> 
> Certainly there needs to be software at the reporting mailbox, to
>  process reports.  That's a fixed requirement and it's outside the scope
>  of the current discussion.
> 
> What remains is differential cost, security and efficacy choices for
>  signaling the reporting address to the MUA.
> 
> The DNS approach will tend to be somewhere between free and cheap for
>  mainstream uses.
> 
> The message-header-field approach is probably pretty cheap, but
>  introduces trust concerns.  It might also have a per-protocol server
>  cost, depending on whether it's possible to affix the header before the
>  retrieval protocol server comes into play.
> 
> The in-protocol approach is probably relatively cheap, but definitely
>  has a per-retrieval protocol cost.
> 
> None of these have the kind of synchronization issues your proposal
>  calls for.

By synchronisation issues I'm not sure what you mean. If you mean the 
upstream system matching UIDL / Message IDs with the stored messages, I 
don't see this as particularly difficult - but I sense you have other issues 
in mind, please explain.

> >> while no doubt true, it is not a clear to me that it's appropriate to
> >>   make it impossible to submit older reports.
> >
> > MTA admins may choose how long to retain copies of messages, perhaps
> > subject to a suggested minimum. So yes it would be impossible in some
> > cases, but is that a problem if 95% of spam can be successfully
> > reported
> 
> You are making an assumption and validating it requires empirical data.
>  I haven't seen any.  Unless you have, the 5% you cite is merely a
>  measure of your hope, not a measure of what we can expect to be true. 
>  In addition, the fact that the design guarantees that there is /some/
>  time limit is a design limitation worth worrying aobut.

I don't see empirical data quoted for the other approaches either at 
present (although I am a newbie here so do correct me if I've got that 
wrong). As I stated I pulled my figures out of thin air. If there's sufficient 
interest in this approach then my assertions can be tested against real-
world data (we'd need a helpful volunteer already implementing TiS - 
probably in webmail - to generate data on how long it takes 'normal' users 
to report TiS from initial message retrieval).

Also see my separate post responding to Chris Lewis re. privacy issues 
where one could have the user/MUA specify the upstream retention period.

cheers,

Andrew.