[Operators] server reputation

Peter Saint-Andre stpeter at stpeter.im
Mon Apr 21 16:29:06 CDT 2008

Jesse Thompson wrote:
> Jonathan Schleifer wrote:
>> Spammers are not a big deal ATM, what we need a solution for is servers
>> with broken s2s, this is hurting the Jabber network far more now.
> It's hard to identify other institutions that offer a federated Jabber
> service to their users.  If I can't easily determine if my users can
> chat with users on X service, then how do I expect my users to figure it
> out?  If those services are available, but not working, then it makes it
> even more difficult.
> One thing to consider is that the reason why spam isn't a big problem
> for most Jabber services is because federation isn't widely utilized.

Typically at jabber.org we have 2500+ open s2s connections. I would call
that widely utilized.

That said, there are many services which don't connect to the network. I
think that part of what we can do here is encourage folks to connect.

> The spammers might be discouraged from targeting us for the same reason
> end-users don't try to chat with their users in another domain.  So, by
> that logic, improving federation might introduce a larger spam problem.

There are tradeoffs with everything. :)

> So, this ties back into Peter's original question: "define some
> parameters for measuring server reputation"... some ideas:
> - The service supports federation, specify the type defined in
> http://www.xmpp.org/extensions/xep-0238.html

Well sure that's a given -- we care about your service only if you federate.

> - The service has a closed user population

Closed, or protected? E.g., a service might have an open-ended user
population but protect it via invite-only policies, certificate login,
or whatever.

> - The service prevents automatic anonymous registration (captcha)

I would see that as one form of protection. But not a very good one.

> - The service's JIDs are identical to email addresses (if the email
> address/domain has a bad reputation, then the im service should too)


> Those parameters would help improve use of federation and help define
> which services can be considered more trustworthy.

I'd add the following considerations as possibilities:

- service allows bidirectional communication (i.e. s2s not broken)
- service maintains proper DNS records including SRV
- service has a certificate from a trusted root
- service requires use of TLS for s2s
- service responds to email sent to xmpp at domain.tld
- service responds to abuse reports via email or phone
- service supports automated abuse reporting (XEP-0236)


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/operators/attachments/20080421/b6b10a41/attachment.bin 

More information about the Operators mailing list