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
* 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,
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
* 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
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
* 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
- 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.