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

Rich Kulawiec <> Tue, 23 June 2009 10:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA0FE3A6E5A for <>; Tue, 23 Jun 2009 03:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yur0fglunpK1 for <>; Tue, 23 Jun 2009 03:05:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF9853A6C7E for <>; Tue, 23 Jun 2009 03:05:33 -0700 (PDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id n5NA5lvP028710 for <>; Tue, 23 Jun 2009 06:05:49 -0400 (EDT)
Received: from ( []) by (8.14.1/8.14.1) with ESMTP id n5NA1Fqa030378 for <>; Tue, 23 Jun 2009 06:01:15 -0400 (EDT)
Received: from (localhost []) by (8.14.3/8.14.3/Debian-4) with ESMTP id n5NA5gCN010762 for <>; Tue, 23 Jun 2009 06:05:42 -0400
Received: (from rsk@localhost) by (8.14.3/8.14.3/Submit) id n5NA5guj010761 for; Tue, 23 Jun 2009 06:05:42 -0400
Date: Tue, 23 Jun 2009 06:05:42 -0400
From: Rich Kulawiec <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
References: <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [Asrg] request for review for a non FUSSP proposal
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Jun 2009 10:05:34 -0000

On Tue, Jun 23, 2009 at 12:14:30AM +0200, Claudio Telmon wrote:
> 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. 

This is unworkable for multiple reasons, not the least of which of scale:
as of a few years ago, there were at least a hundred million compromised
systems, and the number today is certainly much higher.  There's no
good way to inform the former owners of those systems, there's no reason
to believe that they'll see the notification (especially if automated,
since the new owners of those systems can prevent them from seeing it),
there's no way to stop those systems from emitting bogus notifications,
the recipients' systems may themselves be compromised, etc.  Not to
mention it's a LOT of work for everyone to keep track of all these tokens.

Any proposal (not just anti-spam) which depends on the presumption that
end-user systems are secure or securable is dead-on-arrival *until*
the zombie problem is solved, and there is at the moment nothing at all
happening to indicate that problem is even being seriously addressed,
let alone "solved".