[Operators] server reputation

[Peter Saint-Andre]

Jesse Thompson wrote:
> 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.

Good point.

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

Heh, that's a depressing thought, isn't it?

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

Correct. We need a much higher bar to account registration. CAPTCHAs may
be part (but not all) of that. And I think we'll need that soon.

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

Both, I suppose.

>> - service supports automated abuse reporting (XEP-0236)
>>
>> Peter
>>
> 
> Jesse

Thanks for the feedback. We have work to do...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- 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/20080422/fb1d3169/attachment-0001.bin