Re: [Asrg] request for review for a non FUSSP proposal

Claudio Telmon <claudio@telmon.org> Mon, 22 June 2009 22:14 UTC

Return-Path: <claudio@telmon.org>
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 B18CF3A6B2F for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 15:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.452
X-Spam-Level:
X-Spam-Status: No, score=-0.452 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 I+PHnXEg63+O for <asrg@core3.amsl.com>; Mon, 22 Jun 2009 15:14:17 -0700 (PDT)
Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 51F853A67E6 for <asrg@irtf.org>; Mon, 22 Jun 2009 15:14:17 -0700 (PDT)
Received: from 88-149-250-16.dynamic.ngi.it ([::ffff:88.149.250.16]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.16+hp3TxXSFvHa; Tue, 23 Jun 2009 00:14:31 +0200
Message-ID: <4A400246.9060103@telmon.org>
Date: Tue, 23 Jun 2009 00:14:30 +0200
From: Claudio Telmon <claudio@telmon.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org>
In-Reply-To: <20090622215251.GA2137@gsp.org>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] request for review for a non FUSSP proposal
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, 22 Jun 2009 22:14:18 -0000

Rich Kulawiec wrote:
> On Mon, Jun 22, 2009 at 11:45:08PM +0200, Claudio Telmon wrote:
>> In this respect, the framework should be effective, since spammers would
>> also need to generate the consent token, which they can't. 
> 
> Why not?  They can run any code they want on any compromised system,
> therefore they can generate the consent token the same way the former
> owner of that system could.

The owner of the compromised system can only generate tokens then
accepted by his address's MTA, the same can the spammer that compromised
the system.
The attacker can collect the tokens provided to the system owner in
order to communicate with other people. It will then be able to send
spam to the owner's correspondents. These, in turn, can see that spam
arrives with the tokens they provided to the system owner, inform the
system owner about this fact and invalidate the tokens. Once the system
security is "restored", the spammer is left with useless tokens.
Collected consent-protected addresses are useless without valid tokens.

-- 

Claudio Telmon
claudio@telmon.org
http://www.telmon.org