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.
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 <yaoziyuan(_at_)gmail(_dot_)com>
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:
server-dev-unsubscribe(_at_)james(_dot_)apache(_dot_)org
For additional commands, e-mail:
server-dev-help(_at_)james(_dot_)apache(_dot_)org
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg