[Operators] server reputation
jesse.thompson at doit.wisc.edu
Tue Apr 22 13:12:56 CDT 2008
Peter Saint-Andre wrote:
>> 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.
I didn't phrase that well. I should have said "isn't widely
discoverable at the user level".
XMPP federation isn't being used by the mainstream non-techies because
they don't know it's available to themselves and to the people they want
to communicate with.
For example, I see MIT.EDU is on this list... I can pretty much
guarantee that researchers at WISC.EDU have no idea that they could use
XMPP to collaborate with researchers at MIT.EDU. With email, it's a
Why don't they know?
- people aren't asking each other for their Jabber IDs.
- registration forms aren't asking for Jabber IDs.
- LDAP directories aren't being fed Jabber IDs.
- business cards don't have Jabber IDs.
So, the solution to the end-user problem of Jabber federation will
ultimately give the spammers the tools they will need to harvest Jabber IDs.
>> 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. :)
Agreed. You must take the bad with the good.
>> 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
> 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.
As in they have an independent identity verification process. Colleges
generally know who they give accounts to, but gmail doesn't.
>> - The service prevents automatic anonymous registration (captcha)
> I would see that as one form of protection. But not a very good one.
It's better than nothing. I think that the fact that some jabber
servers make it so easy to register for an account on the fly will be a
big problem in fighting spam. I worry more about a bot registering a
fake jabber.org account than I worry about a spammer setting up a new
jabber domain. Setting up a new domain is relatively hard for a
spammer, and the domain will only be effective for a short time
(assuming server reputation works). On the other hand, creating fake
accounts on trustworthy services is easy, effective and immune to any
server reputation system.
>> - 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
Responds, or accepts?
> - service supports automated abuse reporting (XEP-0236)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3340 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/operators/attachments/20080422/db0a675c/attachment.bin
More information about the Operators