[Operators] server reputation

[Jesse Thompson]

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 
different story.

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.
- etc...

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

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)
> 
> True.
> 
>> 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)
> 
> Peter
> 

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