On Wed, Nov 11, 2015 at 12:42:17PM +0100, Georg Lukas wrote: > * Dave Cridland <[email protected]> [2015-11-11 08:58]: > > > What do you suggest to replace it with? > > [...] we need, I think, a mechanism which takes a potential new user > > through new account creation, and helps in configuring their client, > > and ideally works across multiple servers. > > And it needs to be as easy as WhatsApp. I don't see a mechanism that > will effectively prevent automatic registrations, that doesn't rely on > a scarce out-of-band resource like cellphone numbers. > > While spam is evil, it won't be solved by deprecating IBR, especially as > it will take many more years until all the servers out there have > adopted the new alternative. > > I think we as a community must develop better mechanisms for spam > detection and prevention, maybe in the form of massive throttling of > incoming c2s and s2s message flows, maybe by improving our monitoring, > maybe by other means. > > I actually like Dave's suggestion from the other thread, to disallow > message sending from untrusted users. What about the following approach: > > 1. User registers with IBR > 2. User sends message > 3. Server (local or remote) flags user as potential spammer > 4. Server stores undelivered message, gives the user a captcha to solve > (via a HTTP(S) link) > 5. User solves captcha > 6. Server forwards/delivers messages > > #3 and #4 could be deployed on c2s and s2s links using different > metrics, and could be repeated more than once if the user is considered > evil. > > C2S: > - age of the account > - IP address reputation (RBL / accounts from that IP / ...) > - number of messages sent vs. received > - roster size > > S2S: > - number of messages received from the remote account vs. sent back > - number of "first contacts" (unsolicited messages) from different > accounts on this server > - if that other server offers IBR
Those metrics are already specified in XEP-0275 section 3, fyi. > > > Example: > > 1. Juliet registers [email protected] > 2. Juliet sends "Hi" to [email protected] > 3. montague.com thinks something is fishy. > 4. The montague.com server responds with > "Your message to [email protected] must be unlocked. Please solve > the captcha on https://montague.com/xmpp/captcha?refid=too5cupoeN > and your message will be forwarded." > 5. Juliet makes a dozen attempts and finally enters a valid text > 6. montague.com delivers Juliet's "Hi", and also sends back to her: > "Thank you for your approval. 1 message has been forwarded." > > This approach could be codified in an XEP, but it can be deployed with > what we have today. This happen to be exactly what XEP-0158 is about. :) > > Servers could even exchange information about which remote servers / > accounts they consider how trustworthy, provided that the security > implications of passing along third-party account names are addressed. I think XEP-0267 and XEP-0268 might be relevant. > > > Georg > -- > || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ > || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || > || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || > ++ IRCnet OFTC OPN ||_________________________________________________|| -- Emmanuel Gil Peyrot
signature.asc
Description: PGP signature
