Re: [Asrg] An Anti-Spam Heuristic

"John Levine" <> Thu, 13 December 2012 05:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F02D1F0CB9 for <>; Wed, 12 Dec 2012 21:44:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.537
X-Spam-Status: No, score=-106.537 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RXTGGRt0WCRU for <>; Wed, 12 Dec 2012 21:44:23 -0800 (PST)
Received: from ( [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by (Postfix) with ESMTP id BCC3821F84FF for <>; Wed, 12 Dec 2012 21:44:22 -0800 (PST)
Received: (qmail 89287 invoked from network); 13 Dec 2012 05:44:20 -0000
Received: from ( by with QMQP; 13 Dec 2012 05:44:20 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50c96b34.xn--hew.k1212;; bh=hWLul/D25gWHDhpkVRsOsQKTFnN+37i4UHS4r2M8mc4=; b=BiDVpUYcOMoetdrshNoNVlx68KYQlMvRDu0rkkmnaHVQPxI7nPIBFMrkiJjYPbDjkRPYqLDdbKyvHyAc4vZbbDm49rQPgsrqS3f8UAE6Yc2S8q+wuEH1ko5/+KTWdqsCCztNNRYRi4dnQQa5DWapezy8Wr26os9xsZ7LjxbEx0E=
DKIM-Signature: v=1; a=rsa-sha256; c=simple;; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50c96b34.xn--hew.k1212;; bh=hWLul/D25gWHDhpkVRsOsQKTFnN+37i4UHS4r2M8mc4=; b=GlJT0i03Ef3Gm9f6B3I/hvORA+h3Baw8lc3CVwUNTPiQu++M4j7iWpFv2/XN5WNPPNrfP2E9P2WklcBCcIMxEbGyz3ihYRYOdt2WWN4Pf6t95jmOLr7jv72+NRKVzRaBFI8XL8v3BWK7kjq2kXgpHGqix8W0CCrjqQwMqiFIL0k=
VBR-Info:; mc=all;
Date: 13 Dec 2012 05:43:58 -0000
Message-ID: <20121213054358.17733.qmail@joyce.lan>
From: "John Levine" <>
In-Reply-To: <SNT002-W1393526B62C0940EF697B2C54E0@phx.gbl>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7bit
Subject: Re: [Asrg] An Anti-Spam Heuristic
X-Mailman-Version: 2.1.12
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: Thu, 13 Dec 2012 05:44:24 -0000

>Steve Atkins,

I'm not Steve, but what the heck.

>and discuss the concepts that I broached. A technical topic not mentioned in
>that article specifically is the use of the sender's email address, recipient's
>email address, and the date and time of the message event to seed or salt a
>random number generator.

It's clever, but since the fundamental problem with proof-of-work is
that the bad guys can do more work than the good guys, the details of
the work aren't particularly interesting.

>reduce spam (2). It could be that your conclusion addresses one criterion (1),
>while other criteria (2) and (3) could be achieved by increasing the
>computational costs of sending and receiving emails.

No, because the bad guys still have more computational power than the
good guys.  You could get rid of spam, but only at the cost of getting
rid of all of the rest of e-mail, too.  

Effective anti-spam techniques have to be things that it's easier for
good guys to do than for bad guys to do.  This turns out to be hard.
It also turns out to be subtle.  For example, both good and bad
senders can apply DKIM signatures to their mail, so signing per se is
not an anti-spam technique.  What makes them useful is that the
signing identifiers can be keys into reputation systems that are
designed to favor good signers.

>Also, what might you think about discussions about versioning and advancing
>email protocols, modernizing email-related computer networking protocols?

SMTP has had an extension mechanism since RFC 1869 in 1995.  There
have been quite a lot of extensions proposed, some of which, such as
pipelining and 8bitmime, are now universally adopted.  Early
definitions of SMTP had commands such as SOML and TURN that were found
either not to be useful, or to have serious security problems, so
they've been deprecated and eventually deleted.  It's not exactly
versioning, but the protocol has evolved somewhat.

There have been a lot of proposals to "replace SMTP", but none have
come anywhere near close to demonstrating sufficient utility to
motivate people to bear the enormous switching costs from the existing
deployed system.