Re: [Asrg] Passive Spam Revocation

Yao Ziyuan <> Tue, 27 October 2009 18:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 60D7A28C185 for <>; Tue, 27 Oct 2009 11:06:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.689
X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[AWL=0.910, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A2GXZdDf7xGe for <>; Tue, 27 Oct 2009 11:06:29 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BA66528C178 for <>; Tue, 27 Oct 2009 11:06:28 -0700 (PDT)
Received: by bwz27 with SMTP id 27so511229bwz.1 for <>; Tue, 27 Oct 2009 11:06:40 -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=Jsyjj/f57H1CnVgLrfXOysdM8mq82BcyTreZwKjXixY=; b=TS/srDbpiEsW5FfnkmJ3E65p9SlIetk8HNxjc3JbjoxTGtBkAJkPFlBRbaC6LnNUFg 2mQmQTgNJlnL4l286n0AnUVN9fg3JdEyUOVmeJvTsToKy8gTmB2ACcqnvx0u0Sk3MRWH JzT297Fg890GeOQYhBo7Xo1gE4XTiu4gB05T0=
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=I5PryqtbIR8wcJbLOfMapEzfOb9Pem6x60N9YsKjpxkYSMd2H3KvGfOmGhjtMlHNMo fKXdZEmoj66uKlZA+OKdJcZz3fFmNHVn+KO5cbuIxBteKwM5RifYyi80TvEX4P10X56G xHrFxlxfWo2uI1cxO3z0P7qpRYVV08jZ6/xFs=
MIME-Version: 1.0
Received: by with SMTP id k6mr2580434bkd.178.1256666799559; Tue, 27 Oct 2009 11:06:39 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 28 Oct 2009 02:06:39 +0800
Message-ID: <>
From: Yao Ziyuan <>
To: Anti-Spam Research Group - IRTF <>
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 18:06:30 -0000

On Tue, Oct 27, 2009 at 11:34 PM, Danny Angus <> wrote:
> 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
> email.
> 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
> demand.
> 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.

A sender may not think it's necessary to solve a test when sending a
message, but changes his mind later, when he realizes the message is
important and a reply is expected but doesn't arrive in time.

> 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
> puzzles.
> 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
> components.
> 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.
> d.
> 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:
> _______________________________________________
> Asrg mailing list