Draft: draft-ietf-sipping-spam-03.txt Reviewer: Geoffrey Dawirs [gdawirs@gmail.com] Review Date: Wednesday 12/27/2006 4:31 PM Review Deadline: 12/31/2006 Status: WGLC Summary: This draft is on the right track but has open issues, described in the review. Comments: As promised, I read the draft and I would like to provide my review in two parts. First, I will provide you a list of things that could be corrected (typos, suggestions of clarifications or other enhancements). Second, I would like to suggest you (for this version of the draft or for the next one) to include new things in (other interesting existing techniques, suggestions of improvements, ...). I will already give you my main ideas, asking you what you think about them. ************* CORRECTIONS ************* - the spam problem would be much less significant had solutions been deployed ubiquitously before the problem became widespread. - the spam problem would be much less significant if solutions had been deployed ubiquitously before the problem became widespread. - The question, however, is what is the meaning of spam when applied to SIP? - The question, however, is "what is the meaning of spam when applied to SIP"? - Since SIP covers a broad range of functionality, there appear to be three related but different manifestations: - Since SIP covers a broad range of functionalities, there appears to be three related but different manifestations: - the spammer proceeds to relay their message over the real time media. - the spammer proceeds to relay his/her message over the real time media. - it costs more for the spammer to make a phone call than it does to send email. - it costs more for the spammer to make a phone call than it does to send an email. - Black listing is an approach whereby the spam filter maintains a list of addresses that identify spammers. - Black listing is an approach whereby the spam filter maintains a list of addresses that identify unsollicited senders, including spammers. - It is worth mentioning that the source of addresses need not be a web site - It is worth mentioning that the source of addresses doesn't need to be a web site only - It is worth mentioning that the source of addresses can be not only a web site - In email, Turing tests are those solutions whereby the sender of the message is given some kind of puzzle or challenge, which only a human can answer. - In email, Turing tests are those solutions whereby the sender of the message is given some kind of puzzle or challenge, which is in theory impossible to solve by a machine but which is trivial for a human. I think we must underline 1. that it is impossible for a machine to solve a Turing test... At least in theory! 2. the TRIVIAL aspect for a human to solve such a test. 3. As many spams are sent by bots (dedicated servers or zombies) and not by humans because of the very high efficiency of machines, blocking such machines thanks to Turing tests will dramatically decrease their productivity, what can make spam not "profitable" anymore! - The application could be made to run in different languages, if the caller indicates their supported languages. This is possible in SIP, using the Accept-Language header field, but this is not widely used at the moment. - The application could be made to run in different languages, if the caller indicates their supported languages. This is possible in SIP, using the Accept-Language header field. Let's be positive! :-) This field is well there, and even it is not widely used at the moment, let's use it! Computational Puzzles I think the first lines of the description of this technique should include the following idea: This technique is similar to Turing tests, in the idea "solve this challenge first, we will communicate after you pass it". It should be also said that this technique is similar as Payments at Risk, in the idea "you will have to spend something if you want to reach me". With Payments at Risk, you spend money to reach your buddy. In Puzzles, you spend computational time. - This kind of identity mechanism is also applicable to SIP, and is in fact exactly what is defined by SIP's authenticated identity mechanism [17] - This kind of identity mechanism is also applicable to SIP, and is in fact exactly what is defined by SIP's authenticated identity mechanism [17]. ************* SUGGESTIONS ************* I know that the list of techniques presented in the draft must not be exhaustive, but when a technique brings a good new way to fight spam, I think that it sould be presented in the draft in order to give the reader an overview of all things that could be installed to fight spam. I'm conviced that a section should be dedicated to RFC 3028 (Sieve: A Mail Filtering Language). I have already written a summary of this technique, where I describe how it can be used to fight spam. Another idea should be included in the draft, because I think that it could be one of the key points to fight spam: the idea of federating lists (blacklists, whitelists and even both!) between users, in order to improve the protection against unsollicited messages. In the beginning of the draft, you talk about whitelists and blacklists. Later, you talk about circle of trusts, builded on "a social network of reputation". How could this social network be builded? Very simple, it can be builded thanks to the presence of buddy lists (considered as whitelist, as told in the draft) and thanks to blacklists that are present in different forms in various IM softwares. Federating information between users about trusted senders and identified polluters could be very helpful to fight spam. On this point too, I have written a summary of how it could work, and I think it could be included in your draft.