BlueWorld Usenet Farm

Long live Usenet, flood-fill propagation, and liberal peering!

This service exists to provide Usenet feed and reader services (text-only) providing some of the longest text-retention available. I would love to find contributors who have the technical knowledge necessary to bring articles from the 80s and 90s into the spool from files in various formats. If you're out there an see this, get in touch. Too many of these archives only exist on "the web" in hands of commercial entities who poorly index them. I'd like to see them return to a real Usenet spool.

Service Status:

I am back-filling the spool with articles as old as we can fetch easily from other NNTP servers. This involves using multiple upstream providers and various tools (suck, pullnews, etc.) to pull articles into the spool. This process is error prone, brings with it spam and mis-placed binary clean-up challenges and as such may take me a long time to get to a point where I'm satisfied.

The spool is publicly available via port 563 (TLS 1.1 or 1.2 required) via hostname news.blueworldhosting.com. Once I'm satisfied with the backfill and my overview database is sane the spool will move around and possibly get split into two. One heavily filtered and one unfiltered except for mis-placed binaries. If you wish to post using this service, please e-mail me for an account. If you post using this service, your privacy is your problem. Headers won't include the posting host IP or account information, but contains enough data for me to know which account posts an article.

This service propagates all articles fed to us by pees in the spirit of Usenet. By default we configure the feed to include/exclude hierarchies and groups of your chosing. If you need a "spam" filtered feed we need to know so the feed can be configured appropriately. This will be done using different servers than included in the default peering configured displayed below. Filtering Usenet articles is error-prone and in my experience rejects enough valid articles that only one of my reader spools are filtered by pyClean and NoCeM.

The transit layer is tuned for high-throughput. We are peered with commercial providers and propagate binary articles. This tuning should not impact text-only or high latency peers. We respect all peers max-connections requests. If you notice overly aggressive connection behavior please notify us. Most text-only peers will see 1-3 connections from us.

My only peering requirement is that our service not be used for abusive purposes (spam, cancel wars, etc.). We feel these terms to be understood by the general Internet population. We cannot prevent our servers from propagating offending articles originating from other sources. While pyClean can be implemented on your feed from us, it does not filter all spam/abuse, and it does filter legitimate articles. If you are a new Usenet server operator and are worried about traffic, we can assure you a filtered text-only feed is at historically low levels.

My servers run INN 2.7.0rc1 on top of FreeBSD, because after 20 years living with Linux for work and pleasure I am sick of it. ;) Inpath data is reported to Top1000, but is useless since only one large provider submits stats, despite several claiming to, thank you to Uzo Reto!

Contact: Jesse Rehmer (usenet at blueworldhosting dot com)

Why?

I have always been fascinated by Usenet servers and flood-fill propagation. In 1997 I was a teenager entrusted to run a ISP in a rural area when the guru who set everything up quit, and I was left to keep it running and growing. The operation was powered by a Cisco 2511 router with octopus cables connected to 16 modems, one Linux and one SCO UNIX server connected to the Internet via a 56Kbps fractional T1. I was able to get a full Usenet feed from our provider, but quickly realized it satured our link and filled the server's hard drive after running the first night. Even after removing most (or maybe it was all) of the binary groups, there was still a constant stream of data causing the server's hard drive to chatter, kept the router and hub's activity lights blinking, and brought a smile to my face. Sadly, we didn't have the funds to keep up with any reasonable amount of storage, and some users began complaining of slow service due to a good portion of our bandwidth being consumed by the Usenet feed, so we killed it. Our upstream provider was the local Telco, who had large DEC AlphaServers running Digital UNIX with a lot of storage and a fractional T3. I wanted to be *that* cool one day. (I'm still not *that* cool.)

As web server usage grew dramatically I gravitated toward that realm and have been an Engineer in one form or another in the Managed Service Provider world. Now I have access to free hardware, more bandwidth than I can consume with the harware I have, and my servers do next to nothing. I knew Usenet wasn't dead, but I didn't realize the binary consumption had soared to 10+Gbps throughput. So I started up a server running INN and began with text-only feeds. I have some interest in binary groups and do post binary content, but on a small scale and not of the nefarious nature, so I appriecate commercial peers willing to exchange some binary groups and who receive articles posted to binary groups from my personal server (not available to the public).

Peering Details

Pathname:		usenet.blueworldhosting.com
Accept From:		usenet.blueworldhosting.com
Send To:		usenet.blueworldhosting.com
Location:		St. Louis, MO USA
Port:			119
Text Hierarchies: 	*
Max. Article Size:	1MB
Feeder statistics:	http://usenet.blueworldhosting.com/feedstats
Sample INN Configurations for a text-only peer:
newsfeeds:

usenet.blueworldhosting.com\
       :*,!junk/!local\
       :Aj,Tm,<1000000:innfeed!


incoming.conf:

peer usenet.blueworldhosting.com {
	hostname: usenet.blueworldhosting.com
}

innfeed.conf:

peer usenet.blueworldhosting.com {
	ip-name: usenet.blueworldhosting.com
}