Hi Dave, thanks very much for your thorough feedback, it's much appreciated!
* Dave Cridland <[email protected]> [2018-02-08 13:44]: > This is basically saying that a small group of server operators will > club together, agree a set of arbitrary spam protection features, and > then cease federating with an arbitrary set of servers after an > arbitrary period. Yes. On the one hand, I don't think that anything more specific would be able to gain consensus, on the other hand I don't think it is needed. This manifesto is a letter of intent, not a precise action plan. > * How does the rest of the world find out about this? This is an excellent question. People reading this can spread the word, we could use the XSF's outreach, and of course the s2s (or c2s) response which is yet to be defined. > [Community and Test Days] I think the idea of Test Days is good, that would allow us to measure the impact and to collect user feedback from servers that would otherwise be cut off. July 1st would probably be a good candidate, but we could also have some earlier test days. Is now a good time to re-ask for the creation of the XMPP SPAM WG? It would coordinate (in public) the efforts required to make this whole thing a thing, like test day announcements, server configuration / plugin development etc. > You write that the "blocking message" - whatever that is - will > contain a reference to this manifesto. I don't think that's going to > work - existing servers simply don't support injecting text messages > into stream errors, and they don't record them either. You're trying > to define protocol through the back door here; you're going to need a > bit more rigour. And even then, I'm not sure it'll work. https://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-policy-violation is perfectly applicable here, IMHO (feel free to create an XEP with a specific machine-readable element): <stream:error> <policy-violation xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <text xmlns='urn:ietf:params:xml:ns:xmpp-streams'> Your domain [service] is blocked, see [URL] for details. </text> </stream:error> Stream errors will be propagated into the presence of contacts on unreachable servers and as responses to messages sent over those links. Another technical approach would be to establish the s2s connections and to reject any traffic coming from those, as discussed during Summit. I'm sure this is feasible today with prosody's mod_firewall and two or three simple rules. Obviously we need to develop server plugins for blocking and infrastructure for maintaining the blacklists, and document their usage. > * Having defined a "Public Server", how does one determine that a > particular domain is such a server? The pragmatic answer is: we do not need to identify all "public servers", only those that send spam. And those identify themselves automatically, in unappreciated ways. > This is singling out a set of domains that are not actually > discernible externally. My server, for example, is not public - you > cannot sign up for an account. So this is clearly not a thing I would > sign. How does your server, though, know to accept connections from my > server - yet not some completely open server? Or should I sign up, > too, saying that I would - if I were a public server - do these > things? I think you are missing the point - signing the Manifesto will not automatically whitelist your server, nor will not signing blacklist you. The Manifesto is a statement of "community intent" on the general direction. It signals the approximate measures we want to take with fighting spam, maybe similar to the email open relay "Operation Secure Your Server": https://web.archive.org/web/20080306235101/http://www.ftc.gov/opa/2004/01/opsecure.shtm It doesn't make sense for private/corporate server operators to sign the manifesto, because there are very many of them, and because their contribution to the IBR bot spam problem is minuscule. But they can use the domain blacklist infrastructure to improve life for their users, and also report misbehaving servers. > To make this work, you need to build the blocking around a list of > known non-compliant servers (which is hard - the spammers can mint new > ones) as compared to a list of servers which would need to be > compliant and are. Minting new servers is not free, and I'm sure we will be able to come up with solutions once this actually starts happening. For now we have hundreds of abandoned servers that are sending spam today. > * How did you decide the feature set? Again, this is about rough intent and not the specific implementation. > Last I looked, jabber.org didn't support traffic throttling. Maybe it > does now, who knows. Do we know this to be important? What's a timely > fashion for response times? Hours, days? Nobody (or almost) supports > XEP-0157 right now - do we know this will help spam/abuse, or will > this simply allow easier targetting of administrators? How do we test > the implicit hypothesis you've outlined here? The Server Policies are kept vague for a reason. It gives servers the opportunity to differentiate on quality of implementation. Kidding aside, they are meant as a general rule of thumb / direction of movement. The exact level of throttling and the maximum reaction times will have to be sorted out in the next months, I don't have exact numbers, and I don't think we need them. If you want to conduct experiments, user studies or any other activities to improve our data, please do so! XEP-0157 is meant to have an easy way for us to report abuse to the responsible server admins. Targeting administrators with spam is actually a good thing for us - it is a direct way of abuse reporting that doesn't require user interaction ;-) > * A way forward > > I think instead of charging into this manifesto, we should collate > some peer-reviewed best practises on preventing spam originating on > your own server, and publish this as a XEP, augmenting it with some > Wiki pages (or similar) explaining how to achieve this on each server. > This should be simple enough to push through, and it may be that it's > just the list of things you have there. This is great, and it is much needed. But it won't solve the problem of abandoned public servers abused by spammers, which the manifesto is about. Really, the only way I see to cope with abandoned public servers is a blacklist, and this is the primary reason why I created the manifesto. But now, with the list of signers, we could actually distribute the effort into a kind of SPAM WG. > Finally, you can have a XEP defining a machine-readable policy > framework for XMPP servers. Yes, there are many things you can have, and nice protocols to develop in the context of federated reputation services, cryptographic trust relationships, blockchain anti-spam proof-of-work, or whatever. Feel free to pursue an academic career in any combination of those. > But this manifesto, right now, is just too simplistic to work. Sorry, The manifesto is not supposed to "work" on its own, it is just paving the way to be able to block abandoned servers, and I'm pretty confident that it is sufficient to achieve that. 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: PGP signature
