Hi, I just posted on this subject to the Standards-JIG list because IMHO we need new JEPs.
- Ian > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ian Paterson > Sent: 28 August 2005 11:40 > To: 'Jabber software development list' > Subject: [jdev] [Standards-JIG] anti-spim techniques > > > 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 > _______________________________________________ jdev mailing list [email protected] http://mail.jabber.org/mailman/listinfo/jdev
