* 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 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. 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. 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 ||_________________________________________________||
signature.asc
Description: Digital signature
