Re: [Asrg] Passive Spam Revocation

Danny Angus <> Tue, 27 October 2009 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4626B3A6912 for <>; Tue, 27 Oct 2009 08:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id miaYhOZWTUJp for <>; Tue, 27 Oct 2009 08:33:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB6753A68FF for <>; Tue, 27 Oct 2009 08:33:55 -0700 (PDT)
Received: by bwz27 with SMTP id 27so337876bwz.1 for <>; Tue, 27 Oct 2009 08:34:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=L6fjCSfDRKW6DtffW7nSNRSC3xDnCWdBkfjPidOQmUE=; b=guDqpQHp4SIhhLjF9qsmErh/MZkwewlCB91nI9HNf4n2TCg7Cg1+Ue+Cr4u9Gj4rIa biqIRiwI9iisGPTO9MPfgWrYuc48s+YmtBE9s1keJe8pNrQv5w/+vj6OktaJX1bE83zP 9IpzI96secQ5n+rfTYltf7pkIXH5dtKSskeEc=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=k2hd80R8lAWGl7FIu4Q38jwX0d59XjKb57d12x93RqdGyvJykX6B4R+fGX3DA4W6B6 hYlLVuAkEskd92BRHcHV/w8o9z2RQleGnsB3k8uA014b9S3ZsZfuPE5cFGPLc3/cjKFD Aru7iUMqnFFZ6CvpKW09TJ9SFwxJPudyVcABA=
MIME-Version: 1.0
Received: by with SMTP id y18mr397994fau.74.1256657646178; Tue, 27 Oct 2009 08:34:06 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 27 Oct 2009 15:34:06 +0000
Message-ID: <>
From: Danny Angus <>
To: James Developers List <>,
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Asrg] Passive Spam Revocation
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, 27 Oct 2009 15:33:57 -0000

Hi Yao Ziyuan,
I see you also posted this to the asrg. I'm shamelessly cross posting
my reply, sorry in advance to *both* lists!

My response is in two parts:

a) I like the fact that the recipient can set up a test which must be
passed by the sender. I also like the fact that the test would be
passive protection when protecting against, for example spam viruses.
In other words the recipient can set up a test, but the test itself
only generates load when the sender considers it worthwhile to take
the test.

However I would prefer to see the test administered by the mail
system, rather then via another channel.
Solving the problem of spam by invoking a channel not currently
involved in mail transport is not really a solution, it is both
delegating the problem to another arena, and changing the nature of

There's nothing inherently wrong with this, but if we are to consider
changing the nature of email and channels involved we assume that we
could design out the problem from the outset by introducing a strong
concept of identity to the process.

If we anticipate a design which uses the mail transport the passivity
advantage breaks down as the sender must be notified that a test
exists. In this case it would fail the criteria for not introducing
*more* load (email) in response to spam.

The goal is to find a solution which reduces the load as it becomes
successful, even if faced with increased demand. What I mean is that a
true solution would be completely passive when confronted with spam,
and in reducing the spam transported would result in a net decrease in

A passive test that meets the criteria would be one in which a test is
published in advance at low cost (perhaps by a third party), and for
which the solution is encapsulated in the message when it is sent.

For example the test may be for the sender to publish SPF records, or
use a mark similar to the habeus warrant mark. A recipient domain can
publish the test in the their T's & C's.

If you want to consider CAPTCHA, perhaps the test would be to
pre-solve a CAPTCHA, send the UID of the puzzle and its solution in
the mail headers, but CAPTCHA is not really low cost, and is still
another channel.

b) the idea of using a CAPTCHA is flawed and has already been
discussed at length by the asrg.

In essence CAPTCHA works where there is less value in solving the
puzzle than it costs to solve.
If you introduce a strong commercial incentive you will start an arms
race which will see people compete to develop systems which can solve
puzzles at a lower cost, and others compete to develop more complex
We must assume that this will happen unless you can describe a test
which can be reasoned to be unable to be solved by a machine.
The fact that CAPTCHA are impractical to solve with current technology
doesn't imply that they are impossible to solve.

This ties in with point a) because it suggests that in operation the
incentive is there for spammers to now not only send spam but also
create additional work for the CAPTCHA component and the quarantine

Even if spammers use systems which can only achieve a low sucess rate
at the test, there is an incentive to attempt the test every time.
This generates additional demand.


On Mon, Oct 26, 2009 at 12:16 AM, Yao Ziyuan <> wrote:
> Passive Spam Revocation (PSR)
> Currently almost all mail systems (e.g. Hotmail and Gmail) use a spam
> filter, which can drop good and important messages.
> I propose an optional feature for current mail systems. The main idea
> is if a message is considered spam, this spam status can be tracked by
> the sender (but not sent to him directly, as the From field can be
> faked). The message can be re-marked as "not spam" if the sender can
> solve a CAPTCHA.
> STEP 1: A is going to send B a message. A's mail client generates a
> random code and puts it in a custom field in the outgoing message's
> header:
>    Code: <random code>
> STEP 2: A's mail client sends the message, waits 30 seconds, and then visits:
>    https://spamstatus.<B's mail domain>/?msgid=<Message-ID>&code=<Code>
> This page displays one of these possible "spam statuses":
>    * MESSAGE CONSIDERED SPAM. (A CAPTCHA is also presented below.)
>    * All other responses mean B's mail system doesn't support this feature.
> In the first case, A's mail client will report the status and the
> CAPTCHA to A. A can choose to solve the CAPTCHA to prove the message
> is not spam.
> Like the idea? Here is the official Google group for it:
> Regards,
> Yao Ziyuan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: