On 8 February 2018 at 15:01, Georg Lukas <ge...@op-co.de> wrote: > Hi Dave, > > thanks very much for your thorough feedback, it's much appreciated!
Thanks for taking it in the spirit it was intended. It seems that your intent, and the manifesto, do not match up in significant ways, and this invalidates much of my criticism. In particular, your Manifesto includes: """ Schedule With our signature under this Manifesto, we assure that our servers are already following the above stated Server Policies. Starting with July 1st, 2018, we will start blocking incoming server connections from Public Servers not following the Server Policies above, if those are forwarding spam messages to our users. The blocking message will contain a reference to this Manifesto. """ In fairness I'd missed the conditional clause there, and the woolly "assume", but neverthless this still reads to me as if the signatories are asserting they're following a specific set of anti-spam related configurations and also blocking server connections from (spammy) Public Servers, if they do not follow the same set. I don't think, reading your response, you intend this meaning. > > * Dave Cridland <d...@cridland.net> [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. I don't see how I'm supposed to read the Schedule part as anything but a precise action plan. If I signed this, as a public server operator, I would be literally signing my intent to configure my server in a particular manner. > >> * 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. > I don't think any of these is sufficient yet. * The XSF's outreach likely reaches less than 1% of servers out there. Even public servers are probably very under-represented here. * People spreading the word takes a *long* time. * Unlike SMTP, textual messages within XMPP are rarely reported back to admins. >> [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. > Maybe. But I'd actually suggest doing that here. >> 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. > Is that the case right now? It wasn't clear that the textual portion of stream errors ever gets anywhere. I don't think it's commonly logged. > 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. > This might work. Doesn't fill me with glee though. > 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. > That's not what your Manifesto says (or more specifically, the Schedule). >> 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. > See above. If that's your intent, the Manifest really needs rewriting another way, and I'm not sure it's at all what I thought it was. (Indeed, if you are aiming for a simple "letter of intent", many of my criticisms do not apply). >> 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. > This I entirely agree with. >> * How did you decide the feature set? > > Again, this is about rough intent and not the specific implementation. > (Again, this isn't what the Manifesto says). >> 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. > Actually I think that's sensible. > 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 ;-) > Right - I think it ought to be good, and perhaps I didn't make this clear. I just worry that placing it in a static list like this isn't the right approach. > >> * 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. > Let me rephrase - I think rather than have a list of specific measures in the Manifesto, you have a (constantly updated) list of specific measures in a XEP that you reference from the Manifesto. And also, yes, blacklists are just fine. We probably want to run one (as well as other lists). >> 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. > So my purpose here was on the assumption you have a specific set of items you which to enforce. Reading your response, though, you just want to blacklist known spammers - and that's entirely fine by me and doesn't need this. >> 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 ||_________________________________________________||