On 2/7/14, 9:32 AM, David Banes wrote:
To get back on topic :)
Why don't we work up a top level XSF policy that say's badly behaving
servers will be blacklisted, and actually run a black list along the
lines of Spamhaus;
http://www.spamhaus.org
We can then publish the list, make diffs available via a simple API, and
wrap that in a process allowing blacklisted server/services to get off
the list. This process sort of works in email land.
Yes we'll have FP's and FN's and yes someone has to build and run it.
But at least then we're offering something of value to existing and
potential new XSF members as well as being seen to do something about
the problem.
All the discussions about how various services and servers manage there
own traffic, or don't, can be on another list.
I prototyped a DNSBL-based process of allowing clients to query the data
from the XMPP Observatory (not for spam blocking, but rather to allow
servers and clients to get information about the TLS capabilities of
other servers). Different types of data could be hosted by a DNSBL for
different purposes - anti-spam, whitelisting, or whatever - was my
thought for a long term plan.
But alas, too many distractions at $work, so I never found the time to
demonstrate it.
It's not that hard to host a DNSBL, technically. It should be fairly
simple for servers to query it. Logistics is the hard part. Someone
has to figure out the submission and de-listing process and implement a
web app + database. Server hosting costs with DDOS protection is
another consideration.
I'm willing to scrounge together some free cycles if there is interest
in pursuing a community driven effort on a DNSBL.
Jesse
