Re: [Asrg] Passive Spam Revocation

[Yao Ziyuan <[e-mail]>]

On Tue, Oct 27, 2009 at 11:34 PM, Danny Angus <[e-mail]> 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 <[e-mail]> 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.)
>>    * MESSAGE CONSIDERED NOT SPAM.
>>    * PENDING. PLEASE TRY AGAIN LATER.
>>    * 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:
>> http://groups.google.com/group/passive-spam-revocation
>>
>> Regards,
>> Yao Ziyuan
>> http://sites.google.com/site/yaoziyuan/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [e-mail]
>> For additional commands, e-mail: [e-mail]
>>
>>
> _______________________________________________
> Asrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/asrg
>