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 <[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
