On 8 February 2018 at 08:31, Georg Lukas <ge...@op-co.de> wrote: > If you run a public server and are committed to fighting outbound and > inbound spam, please review the text and let me know if you would agree > to sign it. Please do not sign it *yet*, in case there is feedback > requiring changes to the text. Please provide any such feedback until > February 28th.
So, I get to be the dissenting voice, it seems. I don't like spam. Or spim, or whatever we're calling it. I like the idea of seeking out bad actors on the network and avoiding federating with them. I even like positively identifying good actors, and if that's possible only federating with them. The notion of tackling this using the same "Manifesto" concept we used to bootstrap to TLS seems, on the face of things, to be sane. But this manifesto seems a triumph of acting before thinking - as laudable as its goals are, I do not think this is practical. 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. * How does the rest of the world find out about this? That's the biggest question, by far. We could creep toward TLS across months by gradual change, defaults, and general awareness in the networking community that TLS was good. We ran test days. And we still lost dozens of domains - but luckily, we have low-level protocol features to indicate that TLS is mandatory for a particular domain. Here, we have none of this. And by the way, I never signed that one, either. The XMPP Standards Foundation's outreach is pretty good, but this is relative. I doubt this email will reach double-figures in percentage terms of even *public* server operators. 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. So in summary, I do not think this manifesto is workable from a logistical standpoint. * Having defined a "Public Server", how does one determine that a particular domain is such a server? 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? Corporate domains - even less likely to be on this list - won't ever be aware of this, and are equally not "public 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. As things stand, I have literally no idea how I would put the blocking into practise, making this entire manifesto unworkable from a technical standpoint. * How did you decide the feature set? 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? It may very well be that you're entirely right here. It all seems quite reasonable. The trouble is, I don't know, and don't know how we can tell in advance. * How did you decide the timeline? You're saying that in just over a year, some bunch of servers will stop talking to some unidentifiable set of servers. Is this practical? Are there going to be test days? This seems relatively simple to solve - a set of test days, or weeks, prior to the cut off seems simple enough to add. Noting that the calendar might change given experimental results would seem practical. * 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. We're also going to need a XEP on - at least - a way of killing a stream for policy violations of the kind you give here, including what policy has been violated. (We have a stream error for policy-violation, https://xmpp.org/rfcs/rfc6120.html#streams-error-conditions-policy-violation - but we could use some additional stuff here to indicate there's a human readable policy to check). At this point, I think a basic Manifesto becomes possible, but you'd still have to have it based around non-compliance rather than compliance-if-applicable. Finally, you can have a XEP defining a machine-readable policy framework for XMPP servers. You might not use this directly from the server in question - you'd ideally want to use a reputation service to find a validated policy (for example, you want to know if a server has had unanswered complaints, check if it really has no open registration, and so on). That's possibly further protocol-level work, and because it relies on semi-centralized reputation services, it's going to be a fundaciously controversial thing to do. But this manifesto, right now, is just too simplistic to work. Sorry, Dave.
