[Operators] Announce: Jabber Spam Fighting Manifesto (for public servers)

Georg Lukas georg at op-co.de
Thu Feb 8 15:01:44 UTC 2018


Hi Dave,

thanks very much for your thorough feedback, it's much appreciated!

* Dave Cridland <dave at 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.

> * 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/operators/attachments/20180208/6d6e498b/attachment-0001.sig>


More information about the Operators mailing list