[Operators] server reputation
stpeter at stpeter.im
Tue Apr 22 23:20:58 CDT 2008
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.
> 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
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
>> Well sure that's a given -- we care about your service only if you
>>> - 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)
>>> 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)
Thanks for the feedback. We have work to do...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/operators/attachments/20080422/fb1d3169/attachment-0001.bin
More information about the Operators