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

Dave CROCKER <dcrocker@bbiw.net> Mon, 08 February 2010 21:07 UTC

Return-Path: <dcrocker@bbiw.net>
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 1083E28C19F for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 13:07:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.581
X-Spam-Level:
X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 CoC16-ce5WDl for <asrg@core3.amsl.com>; Mon, 8 Feb 2010 13:07:22 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id DD8823A70AF for <asrg@irtf.org>; Mon, 8 Feb 2010 13:07:22 -0800 (PST)
Received: from [192.168.1.43] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o18L85Zn011361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Feb 2010 13:08:10 -0800
Message-ID: <4B707D33.1060608@bbiw.net>
Date: Mon, 08 Feb 2010 13:08:03 -0800
From: Dave CROCKER <dcrocker@bbiw.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Andrew Richards <ar-asrg@acrconsulting.co.uk>
References: <4B6C6D35.1050101@nortel.com> <201002081911.55443.ar-asrg@acrconsulting.co.uk> <4B706386.5080501@bbiw.net> <201002082056.23128.ar-asrg@acrconsulting.co.uk>
In-Reply-To: <201002082056.23128.ar-asrg@acrconsulting.co.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10366/Mon Feb 8 08:41:04 2010 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Mon, 08 Feb 2010 13:08:10 -0800 (PST)
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: Mon, 08 Feb 2010 21:07:24 -0000

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.


>> 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.


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net