Ensuring SPIM will not be worthwhile, even with a network of 'zombie' client or server machines, clearly needs multiple measures. IMHO we need to move forward ASAP with some of the good ideas that Tijl, Sander and others were putting forward on the JDEV list yesterday. (I've tried to summarise them here.)
Has Sander (or anyone else), got some time to write a first draft of a new generally-useful 'Bot-Proof Challenges' JEP? This could include inband delivery of images and CPU challenges (e.g. find a string where the least significant bits of the hash have a specific value). The first application of that new 'building block' protocol could be another new JEP that either extends or replaces JEP-0077 (In-Band Registration). I'd also like to see a procedure and protocol JEP that allows a client to complain about the SPIM it is receiving (both to its own server and to the sending server). This JEP might also make use of the Bot-Proof Challenges to exonerate people and to create a barrier against malicious multiple reporting. If despite our other efforts we find people are still bothered by SPIM, then clients could use the Bot-Proof Challenges (with JEP-0155?) to verify each new correspondant, who is not on the roster, is human. Server Implementors and Administrators have a lot more weapons against SPIM: - Dialback - Karma - Invite-only and/or out-of-band registration - Outgoing message filtering? - IP blocking (If admins don't use some or all of these approaches then I agree they should be accountable for any SPIM their users send.) Once enough clients implement e2e encryption then people could insist that all correspondants use it, making SPIM far more CPU-expensive. As I am confident we will be able to mitigate the SPIM problem to the extent that: 1. People do not need to block all messages from people not on their rosters. 2. All public servers are free to interconnect (as long as they have a domain cert from a JSF approved authority and do not appear on the authority's black list). As Sander mentioned, the JSF-approved certificate agreement should legally disallow SPIM and provide tough penalty clauses for clear abuses. (These agreements would probably need to be drawn up under the laws of countries that are not friendly to spammers.) > what will happen if a CA gets blacklisted? Any certs it issues after the blacklisting are invalid. Certs issued before *may* become invalid later if their owners abuse (another CA could be appointed to handle that). > providers even might want to send email over XMPP... ;-) Seriously, I do expect email SPAM will motivate most people to switch from email to offline IM delivery within the next few years (as long as we minimise SPIM and improve our offline message handling implementations). > The call to Google to open their network now, today, is not > very realistic, because we have a lot of work to do first. Yes. - Ian _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
