Re: [Asrg] Passive Spam Revocation

Alessandro Vesely <> Mon, 26 October 2009 07:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 69B073A6898 for <>; Mon, 26 Oct 2009 00:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.719
X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gvLenl-NjLd4 for <>; Mon, 26 Oct 2009 00:56:50 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 287583A6819 for <>; Mon, 26 Oct 2009 00:56:49 -0700 (PDT)
Received: from ( []) (AUTH: CRAM-MD5, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by with esmtp; Mon, 26 Oct 2009 08:57:01 +0100 id 00000000005DC034.000000004AE5564D.000006DE
Message-ID: <>
Date: Mon, 26 Oct 2009 08:57:02 +0100
From: Alessandro Vesely <>
User-Agent: Thunderbird (Macintosh/20090812)
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 26 Oct 2009 07:56:51 -0000

Yao Ziyuan wrote:
> 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.

The mailing system described below is equivalent to direct-to-MX 
mailing, except for the fact that the message is pre-fetched via 
regular SMTP, which may be regarded as a compatibility hack. In 
facts, the client connects directly to the recipient's server in 
order to formalize the submission.

Direct-to-MX delivery has been discussed previously on this list. 
Bill pointed out that funneling email through MSA systems run by 
providers had been conceived for the very purpose of authenticating 
authors and introduce domain-level accountability. See

Allowing direct-to-MX delivery is likely to introduce more spam. The 
requirement of human interaction would only raise the entry level 
for leveraging such opportunity. CAPTCHAs can be solved by low cost 
personnel, as it is currently done, e.g., by 
at 0.002 USD per solved CAPTCHA. Although those micro-payments might 
be considered similar to e-postage, that money would flow toward the 
wrong ranks.

In addition, letting senders monitor whether their messages have 
been marked as spam may turn out to be an advantage for those 
senders who can tweak their messages until they cannot be discerned. 
That's the reason why several servers drop spam rather than 
rejecting it.

Finally, if widely adopted, PSR would hinder any form of mass 
mailing, even legit.

> 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:
>     PSR-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=<PSR-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.