Well Dave, Server directories/buddies, server vcards, incident handling.. The list is long, but since the tools are already there from years.. it's pointless to be dissenting. If they're never advanced of status of course adoption will be nil or almost and we get into this usual parade of circular arguments over and over.
Working around contact subscription is probably the correct approach as from when I implemented actual anti-spim countermeasures (without just blocking s2s) I observed that almost the totality of messages from non local, not subscribed sources is SPIM on xmpp right now. But complaining about the lack of tools or their adoption frankly doesn't make sense, because in the end it's the XSF discouraging that in the first place. And if a manifesto is the only way to help advancement, as usually is around here, then, as usual, *pin it on the wall*. 🙄 ---- Dave Cridland ha scritto ---- >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.