Free news servers

Long-form reference · 7,572 words · about a 33-minute read

The page this page used to be

What stood here was a table, and it was compiled the only way such a thing could honestly be compiled: by connecting to each address in turn and seeing what happened. A conscientious list-keeper recorded how many groups a server carried, whether it accepted postings as well as reads, how quickly it answered, and whether it had gone quiet since last time — and then did the whole round again the following month, because an address that worked in March might be firewalled by May. The tables were perishable in the way that timetables are perishable, and for the same reason: they described arrangements that other people were free to change without notice.

The genre had its own small industry. Dedicated sites automated the scanning and published rankings of the survivors; forum threads traded addresses the way earlier generations traded shortwave frequencies, and some of those threads still point here. It also had an etiquette, of the kind that networks generate spontaneously and enforce badly: do not hammer a slow server with parallel connections, and do not broadcast the address of a university machine that is plainly open by accident rather than by policy. The etiquette was observed about as well as etiquette usually is.

Every one of those lists is now a fossil. The servers they named have been closed, firewalled or switched off, in most cases for the better part of two decades, and the pages that mirror them faithfully reproduce a network that no longer exists. This page is a former member of that genre and has stopped pretending otherwise. What follows is not a list but an explanation: what these servers were, what the protocol underneath them actually does, why open access was normal and then stopped being normal, and what a person who arrives here looking for one is most likely to actually need.

Why a news server was standard furniture

For most of the 1990s a news server was part of the ordinary equipment of a network. Internet providers ran one because customers expected it in the way they expected a mail server. Universities ran one because Usenet had grown up on university machines and the department had never seen a reason to stop. Sizeable companies ran one because the software shipped with the operating system and somebody had turned it on. A good many of these servers were configured the way the era configured everything — permissively — and would answer any client that connected to TCP port 119 and spoke NNTP. This was rarely deliberate generosity. It was the default, on a network whose trust model still assumed that a stranger was probably a colleague at another site.

The institutional logic is worth stating plainly, because it explains why the access was free without being charitable. A news server existed to serve the people who had paid for the machine: a university's students and staff, a provider's subscribers, a company's engineers. It filled itself by exchanging articles with a handful of peers under arrangements that were reciprocal and largely informal — one administrator agreed to feed a neighbour, the neighbour fed back, and frequently neither money nor paperwork changed hands. Against that background an outsider who connected and read cost the operator almost nothing, because the articles had already been fetched and written to disk for local use. Open access was a by-product of a system built for somebody else. Nobody had decided to run a public service; they had merely declined to prevent one.

That distinction turns out to be the whole story of this page. A by-product survives exactly as long as the thing producing it, and no longer. When carrying news stopped being a normal cost of running a network, the free access that fell out of it stopped too — not because anyone withdrew a gift, but because the machine it fell out of had been switched off.

The specifications, and what they actually say

Usenet is defined by two families of document, and confusing them is the commonest error in accounts of it. One family specifies what an article is: the header fields, their syntax, and the rules for handling them. The other specifies how articles move between machines. A news server implements both, which is why its behaviour looks arbitrary until you know which document it is obeying.

The article format came first. RFC 850, Standard for Interchange of USENET Messages, was written by Mark Horton and issued in June 1983; a bracketed note at the head of it says that the memo is distributed as an RFC only to make the information easily accessible to researchers in the ARPA community, and that it does not specify an Internet standard. RFC 1036, of December 1987, obsoleted it over the names of Horton and Rick Adams, and says of itself that it reflects version B2.11 of the News program — a specification written to describe the dominant implementation rather than the other way round. A thorough revision by Henry Spencer, universally known as Son of 1036, circulated in draft through the 1990s and was influential without ever being formally published; it was finally issued as RFC 1849 in March 2010, in the Historic category, its abstract explaining that by the early 1990s it had become clear that RFC 1036 was badly in need of repair. The replacement that did carry standards-track weight had arrived a few months earlier: RFC 5536, Netnews Article Format, and RFC 5537, Netnews Architecture and Protocols, both of November 2009, each of which obsoletes RFC 1036 — and which, between them, also obsolete Spencer's document, so that the draft and its successors were published in the reverse of the order in which they were written.

The transport family begins with RFC 977, Network News Transfer Protocol, by Brian Kantor of the University of California, San Diego, and Phil Lapsley of the University of California, Berkeley, subtitled A Proposed Standard for the Stream-Based Transmission of News and dated February 1986 on its own title page. Its opening paragraph is a fair description of what a news server still does: the distribution, inquiry, retrieval and posting of news articles over a reliable stream, with indexing, cross-referencing and the expiration of aged messages provided as well. Over the following decade implementers added commands the specification did not contain, and in October 2000 Stan Barber collected the results in RFC 2980, Common NNTP Extensions — an informational document, explicitly not a standard of any kind, whose purpose was to write down what had already happened in the field.

The tidying-up came in a single month. In October 2006 the IETF published RFC 3977, Clive Feather's revision of NNTP, which obsoletes RFC 977 and updates RFC 2980; alongside it, RFC 4642 on the use of TLS, RFC 4643 on authentication, and RFC 4644 on streaming feeds, the last two of which likewise update RFC 2980. Two later documents complete the set: RFC 8054, of January 2017, which adds a compression extension, and RFC 8143, of April 2017, which updates RFC 4642 with better advice on TLS. That is the entire specification stack of a news server, and it is a short shelf for a system that has been running since 1980. The client's half of it — which commands a newsreader sends and in what order — is set out on this directory's own page about accessing Usenet today, and is not repeated here.

Two jobs, one protocol

The single most useful thing to understand about a news server is that the phrase covers two different machines doing two different jobs, and that whether one of them can be open to the public depends entirely on which job it is doing.

A reading server faces people. It holds a spool of articles, keeps an index over them, and answers requests: give me the groups you carry, select this group, list the overviews for these article numbers, send me this article, accept this posting. Its load is dominated by many small reads from many clients, and it needs to know something about who is connecting, because it is also an entry point for new articles.

A transit peer faces other servers. Its job is to take everything its neighbours have that it lacks, and to offer everything it has that they lack, as fast as the link allows. It has no interest in threading, in unread counts, or in whether a human is watching. Its load is a continuous bulk flow in both directions. Most packages can do both jobs at once, and most sites ran them on one machine; the two roles are nonetheless separate, and on large installations they are commonly split across separate machines, along with the numbering and storage functions.

The distinction is old enough to be written into the port registry. IANA assigns TCP port 119 to nntp, TCP port 563 to nntps for sessions wrapped in TLS from the outset — and TCP port 433 to nnsp, described in the registry, in so many words, as NNTP for transit servers. Three ports, two jobs, one protocol.

The mechanics diverge too. In plain NNTP a peer offers an article with IHAVE, quotes its message-id, waits to be told whether the other end wants it, and only then sends it. RFC 4644 is blunt about the cost: because IHAVE cannot be pipelined, the need to stop and wait for the far end's response greatly restricts the throughput that can be achieved. The streaming extension standardised in that document splits the query from the transfer, into CHECK and TAKETHIS, which can be pipelined: a feeder fires off a long run of enquiries without waiting for each answer, uses the replies to build a list, and then sends that list as a pipelined run of articles. A client may also send an article with TAKETHIS without asking first, though the specification says it should not do so for every article unless the site has deliberately configured it that way. Both commands were already in wide use and were formalised rather than invented; the same document deprecates the older ad-hoc MODE STREAM command they grew out of, while documenting it anyway because it was too ubiquitous to omit.

This is where the open-server question is actually decided. Letting strangers read from a machine that already holds the articles costs bandwidth and nothing else. Letting strangers inject articles into it costs the operator's standing with every peer downstream, because everything injected propagates outward under that server's name. The permissive servers of the 1990s did both, generally without having thought about it; the running argument about what to do when that went wrong took place, as such arguments did, in the administrative groups described on the news.* hub.

The software that did the work

The programs are worth naming, because the capabilities of the servers on any old list were the capabilities of whichever of them the site had installed. A News, written at Duke by Steve Daniel and Tom Truscott and handed out on tape at the June 1980 USENIX conference at the University of Delaware, was designed for a network expecting one or two articles a day. B News, produced at Berkeley by Matt Glickman and Mary Ann Horton and in use from 1981, was written because that assumption had already failed — by late 1983 the traffic was running at some fifty articles a day, which was then an alarming figure. It became the dominant server software, and it is the reference implementation behind both RFC 850 and RFC 1036; releases from 2.10.2 onwards were maintained by Rick Adams, who is the second name on RFC 1036.

One B News change is visible in the illustration on this page and is worth explaining, because it is the ancestor of how articles are stored to this day. Before version 2.10 every newsgroup was a single directory sitting beneath one parent, which slowed the machine down as the group list grew and — because of an old Unix limit on filename length — required the first fourteen characters of every group name to be unique. B2.10 split group names at the dots and nested the directories accordingly. That layout was carried into C News and into INN, and is still what many newsreaders and caches expect to find.

C News, by Geoff Collyer with Henry Spencer at the University of Toronto, was presented at the Winter 1987 USENIX conference in Washington, D.C. as a portability-minded replacement: it ran on many variants of Unix and even on MS-DOS, and its article-filing program, relaynews, was written to process articles in batches where B News had run once per article. The authors claimed relaynews could work nineteen times as fast, and titled the accompanying paper News Need Not Be Slow.

InterNetNews, released by Rich Salz in 1991 and presented at the Summer 1992 USENIX conference in San Antonio, was the first news server with NNTP built in rather than bolted on, and its architecture is the one the modern reader will meet. The daemon innd runs continuously, receiving articles from the network, filing them and recording which peers should get them; a separate program, nnrpd, serves newsreaders. That split is the reading-server-and-transit-peer distinction made concrete inside one package, and it is why an operator can offer reading to the public while keeping peering strictly private.

Two later additions changed what a server could afford. The cyclic news file system, CNFS, implemented for INN by Scott Fritchie, appends articles serially into large pre-allocated container files instead of storing each as its own file, and when a container fills, the writing wraps round to the beginning and overwrites the oldest entries. That removed the operating-system overhead of managing thousands upon thousands of small files, and it made the storage requirement predictable in advance, at the cost of being able to retain articles by age rather than by space consumed. And innfeed, by James Brister, fed articles out continuously in the way innd took them in, replacing the batched innxmit and cutting the interval between a posting and its appearance elsewhere from hours or days to seconds or minutes; an independently written program called nntplink had provided a comparable function earlier. Alongside all of these sat transit-only packages, built to move articles between backbone machines and not to serve readers at all.

None of this software has gone away. INN is still under active development, maintained by volunteers with its development hosted by the Internet Systems Consortium, which also publishes the administrative files that tell a server what the namespace looks like. The reason there are few open servers is not that the programs stopped working.

Article numbers, overviews, and what a reader depends on

RFC 3977 says that articles are stored and indexed under three types of key, and the difference between them explains several things that puzzle people about Usenet. The first is the message-id, which is globally unique: one article, one identifier, the same on every machine that holds it. The second is a newsgroup name together with an article number within that newsgroup. The third is the arrival timestamp — the moment the article reached this particular server.

The second key is the one that causes trouble, because it is local. Within one group on one server there must be exactly one article with a given number, and an article must not have two different numbers in the same group; but an article cross-posted to several groups may hold a different number in each, and the same group-and-number pair may refer to entirely different articles on two different servers. Numbers are issued in order of arrival, so a server must give a later-arriving article a higher number than an earlier one, and the specification says it should hand out the next sequential unused number. The permitted range runs from 1 to 2,147,483,647, and the specification notes drily that this limit will probably be raised by a future revision and that developers are advised to use internal datatypes capable of handling larger values in anticipation.

The practical consequence is that article numbers are bookkeeping, not identity. A newsreader's record of what you have read is a set of numbers meaningful only against the server that issued them, which is why moving to a different server can present you with a group you have already read, and why an archive and a live group cannot be lined up article for article. The one place the numbering surfaces publicly is the Xref line a reading server adds when it files an article, listing the groups the article was placed in together with the number it received in each — which is how a newsreader knows not to show you the same cross-posted article five times.

The second mechanism a reader depends on is the overview. Displaying a group as a threaded list requires, for every article, its subject, author, date, identifier and ancestry — and fetching all of that by opening every article is precisely the operation that brings a server to its knees. In 1992 Geoff Collyer gave C News an index facility called News Overview, universally NOV, which precomputes those fields into a compact database the server can serve directly. Newsreaders reached it through the XOVER command, which RFC 2980 documented as common practice and RFC 3977 standardised as OVER. The specification fixes the first eight fields and their order: the article number, then the contents of the Subject, From, Date, Message-ID and References headers, then the byte count and the line count. Everything a reader shows you before you open anything comes from those eight columns, and that is why a group with tens of thousands of articles opens in a second on a connection that would take an hour to download it.

Retention, completeness, and the size of an article

Two words decide whether a given server is any use to you, and both mean something concrete.

Retention is how long a server keeps an article before expiring it out of the spool. It is a property of that individual server, not of Usenet, which has no memory of its own: the same group may reach back a fortnight on one machine and a decade on another, and neither figure is more correct than the other. It is quoted separately for text and for binaries, because the economics of the two are not comparable, and it is harder to measure from outside than it looks — inspecting the oldest article in one group is a poor test, since expiry policies vary between groups and arriving articles carry dates that are sometimes simply wrong.

Completion is the other half, and it is the harsher one: no server can offer more than its feeds actually delivered to it. The obstacle to measuring it is that nobody can observe how many articles were injected across the whole network — articles may never leave the machine they were posted on, or may fail to reach the transit cloud at all — so completion cannot be computed directly, only estimated by comparing several servers with one another. Large articles fare worst, being both the likeliest to be dropped in transit and the least well propagated. A server is therefore never a view of Usenet; it is a view of what reached that machine and has not yet been deleted.

The size of an article is worth stating with its source, because it is the number that makes the rest of this page arithmetically obvious. Spencer's Son of 1036 — drafted in the early 1990s, published as RFC 1849 in 2010 — requires implementations to handle an article of at least 65,000 octets, headers and line endings included, gracefully and efficiently; it says they should manage at least a million; and it asks posters to hold to at most 60,000 octets unless they are posting only within a cooperating subnet known to handle more. The note attached to that recommendation is candid about why the two figures differ, and about what happens when they are ignored: an article larger than 64K, once header growth and differing line-ending conventions have had their way with it, simply was not transmitted reliably on the networks of the day, and the occasional huge article that appeared by accident or through ignorance typically left in its wake, in the document's own words, trails of failing software, system problems and irate administrators.

Sixty thousand octets is a generous ceiling for a discussion post and a derisory one for a photograph. Everything that followed proceeds from that gap.

Spam, and the end of anonymous injection

The date usually given for the end of the innocent period is 12 April 1994, when Laurence Canter and Martha Siegel, lawyers offering to handle the paperwork for the American green-card lottery, sent an advertisement headed Green Card Lottery – Final One? to at least 5,500 newsgroups. They were not the first to advertise on Usenet, and the scale alone would not have made them notorious. What did was the method: rather than cross-post one article to many groups, so that a reader would encounter it once, they posted a separate copy into each group, so that a reader met it again in every group they followed. Their provider's mail servers crashed repeatedly for two days under the volume of complaints, and it terminated their service; in June the pair repeated the exercise across a thousand groups, and this time Arnt Gulbrandsen assembled a cancelbot that trawled Usenet and killed the copies within minutes.

What made this cheap was exactly the property the free-server lists were cataloguing. An open server took articles from anyone who connected: no account, no identity, no comeback, and no way for anybody afterwards to establish which human being had injected what. The parallel with the open mail relay is not an analogy but the same event in a different protocol — a permissive default, inherited from a network of colleagues, discovered by people who were not colleagues. Relays were closed one by one as each was found and abused; open news servers followed the same curve, each publicised address being used until its operator restricted it to local users or shut it down.

The response — cancel messages, the Breidbart index that Seth Breidbart devised for measuring the reach of a multi-posting, and the long argument about whether cancelling anything was legitimate — belongs to the history of the alt.* hierarchy and the administrative groups, and is told there rather than here. The part that matters for this page is narrower and permanent: after 1994 an operator who left injection open was not being generous but negligent, and every subsequent free service has been built around knowing who is posting.

The arithmetic of a full feed

Spam changed the manners; volume changed the budget. The figures below are attributed to altopia.com and tabulated in Wikipedia's article on Usenet, and they measure the whole daily feed — everything a server accepting all groups would have to receive, in one day. They are reproduced with their dates because they are meaningless without them.

• December 1996: about 4.5 GiB a day.
• January 1998: 12 GiB a day, across 554,000 articles.
• January 2000: 82 GiB a day, across 858,000 articles.
• January 2001: 181 GiB a day, across 1.24 million articles.
• January 2005: 1.52 TiB a day, across 5.09 million articles.
• January 2010: 5.42 TiB a day, across 15.66 million articles.
• January 2015: 17.87 TiB a day, across 44.19 million articles.
• January 2020: 62.40 TiB a day, across 107.49 million articles.
• January 2021: 100.71 TiB a day, across 171.86 million articles.
• February 2024: 274.49 TiB a day, across 400.24 million articles.

The last line contains the entire argument. Divide the volume by the count and the average article of February 2024 weighs roughly three-quarters of a megabyte — more than ten times the ceiling that Son of 1036 asked posters to respect, and around two orders of magnitude above an ordinary text post of a few kilobytes. Those are not discussions. They are files, chopped into article-sized pieces and reassembled by the recipient's software, and a server that carries them is not hosting a conversation but operating a distribution network.

The shape of the namespace shows the same thing from another angle. The active file that the Internet Systems Consortium publishes, in the copy retrieved while this page was written on 26 August 2026, lists 45,003 groups. Of those, 20,466 are in alt.*, and 2,618 of the alt.* groups are under alt.binaries.* alone — against 1,898 groups in the whole of the Big Eight. The binaries branch is thus about one group in seventeen by name and the overwhelming majority of the network by weight. What that list is, how it is maintained and why no such list can ever be authoritative is the subject of the newsgroups list page, which owns the question and should be read for it.

For an operator the consequences were sequential rather than simultaneous. First the storage: retention on a full feed became a capital expenditure that grew every year without any corresponding growth in the number of customers using it. Then the liability: a service that carried, unread and unfiltered, whatever its peers chose to send became an awkward thing for a large company to own. And underneath both, the plain arithmetic of attention — the readers had left for the web, first for message boards and then for weblogs, so the expense was being incurred on behalf of a shrinking minority whose support calls were out of all proportion to their number. Writing in PC Magazine in July 2008, under the title R.I.P Usenet: 1980–2008, Sascha Segan put the decisive change in the late 1990s, when the binaries groups began taking up huge amounts of space and network traffic and providers, as he put it, sensibly started to wonder why they should reserve big chunks of their own disk for pirated films and pornography. Declining readership, cost and liability are the three reasons that appear, in one order or another, in nearly every withdrawal notice that followed.

June 2008, and the withdrawals that followed

The best-documented turning point has a press release attached to it. On 10 June 2008 the Attorney General of New York, Andrew Cuomo, announced agreements with Verizon, Time Warner Cable and Sprint — the company Wikipedia's account names as Sprint Nextel — concerning the distribution of child sexual abuse imagery. According to the announcement, an undercover investigation by his office had reviewed millions of pictures over several months and uncovered 88 newsgroups holding 11,390 such images between them. Under the agreements the three companies would block access to those newsgroups, purge from their servers the websites on the registry maintained by the National Center for Missing & Exploited Children, implement a system for responding rapidly to user complaints, and pay collectively 1.125 million dollars towards further work by the Attorney General's office and the Center. The announcement referred throughout to Newsgroups, capitalised, as a service reached through internet providers; it did not name Usenet as such, and the campaign was not framed as being about Usenet.

What the companies did with their news services went considerably further than the agreements described, and differed from one to the next. Time Warner Cable stopped offering Usenet access altogether. Verizon reduced its feed to the Big Eight hierarchies. Sprint stopped carrying alt.* entirely. AT&T, which responded to the campaign separately rather than signing, dropped alt.binaries.*. The reach of those four decisions mattered more than their number: writing in PC World on 7 October 2008, under the title Usenet: Not Dead Yet, David DeJean observed that AOL, which had already left Usenet, together with the four providers that responded, were the five largest internet service providers in the United States and held more than half the national market between them. He also recorded the suspicion, held by some observers at the time, that the campaign had supplied an occasion rather than a reason — that a service both costly to carry and little used was being dropped for its own reasons, under cover of a better one. That remains a suspicion; the record does not settle it, and this page does not pretend to. Some providers that dropped their feeds afterwards did not cite the campaign among their reasons at all.

The withdrawals continued under their own momentum, and the dates are worth having in one place:

• January 2005 — AOL announces the end of its integrated newsgroup service, citing the growing popularity of weblogs, chat forums and online conferencing.
• 8 June 2009 — AT&T announces that its Usenet service will end on 15 July 2009.
• August 2009 — Verizon announces that its newsgroup service will end on 30 September 2009.
• May 2010 — Duke University decommissions its news server, citing low usage and rising costs; the shutdown was reported on 20 May.
• 1 June 2010 — Microsoft ends support for its public newsgroups on msnews.microsoft.com, directing users to web forums.
• 2010 — Cox and Atlantic Broadband, which had held out through the 2008 round, drop their feeds.
• 31 July 2010 — JANET, the British academic network, discontinues its Usenet service, citing Google Groups as the alternative.

The Duke entry is the one with the irony in it: Usenet was conceived in 1979 by Tom Truscott and Jim Ellis at Duke, who established the first link to nearby Chapel Hill using shell scripts written by Steve Bellovin, and the institution where it started gave the reasons every other operator was giving by then. Microsoft's withdrawal is documented in detail, from the announcement to the last articles, on the microsoft.* page. For the Dutch case, where the general direction is not in doubt but a provider-by-provider timetable cannot honestly be reconstructed from the surviving sources, see the nl.* hierarchy page, which sets out both what can be dated and what cannot.

By the early 2010s the bundled provider news server — the thing every free-server list had quietly assumed would always be there as a fallback — had become the exception. The lists did not become wrong all at once. They became wrong one line at a time, which is a slower and much less noticeable way for a document to fail.

What survived, described as categories

Access did not end; it stopped being incidental and started being something somebody deliberately provides. Four categories account for essentially all of it, and they are worth understanding as categories, because the individual members change and the categories do not.

Commercial subscription services. These are storage businesses. They carry the binary hierarchies, they compete on retention and completion, and retention is the headline number in their advertising because it is the product: the figures are quoted in thousands of days, and the major providers advertise retention of more than twelve years. The trade has consolidated onto a small number of very large operations, with many visible brands reselling capacity from a smaller number of underlying networks; the economics of moving a full binary feed are such that providers generally peer only where they already meet at an internet exchange. This page does not name or rank them. What the old open-server lists were hunting for — a full feed including binaries, held for a long time — is now bought rather than found, and that is the single largest change since those lists were written.

Free text-only services. These carry the discussion hierarchies and not the binaries, which is precisely what makes them affordable to run: text has never grown the way binaries grew, so the whole text side of Usenet remains small enough for a modest machine to carry in full and keep for years. They generally require registration. The two named in the box above this article are the page's inheritance from its list-making days and remain there for that reason; the name of the better known of the two is a joke at the expense of the Eternal September that began when consumer providers started connecting large numbers of new subscribers in 1993. Any free service promising binaries deserves the suspicion you would extend to any other offer to store unlimited quantities of other people's files for nothing.

Institutional servers. A number of universities, research networks, clubs and employers still run NNTP for their own communities, sometimes carrying local hierarchies that exist nowhere else. These are not public and are not meant to be; the correct approach is to ask whether the institution you already belong to has one, which is the modern form of the old advice about not publicising somebody else's machine.

Local and personal servers. A small server on your own machine can pull a subset of groups from an upstream feed, hold them locally and serve one household or one person. The best-known program of this kind, leafnode, is a store-and-forward NNTP proxy written in 1995 by Arnt Gulbrandsen — the same person whose cancelbot had met Canter and Siegel's second campaign the year before — and aimed at small sites with a few active groups. It is a sensible answer for anyone who wants offline reading or a private archive, but it is a category rather than a recommendation: it presupposes that you have somewhere upstream to pull from, which returns you to the three categories above.

Authentication, and what free means now

The commands a server uses to ask who you are were an extension long before they were a standard. AUTHINFO, in its USER and PASS form, circulated for years as common practice, was written down descriptively in RFC 2980 in October 2000, and was finally standardised in RFC 4643 in October 2006 — the same month as the NNTP revision itself. The transport underneath is the familiar pair: port 119 for a plain session, which can be upgraded in place with STARTTLS, or port 563 for a session encrypted from the first byte.

The reason a modern free server asks you to register is contained in the previous sections. An account makes a posting traceable to somebody, which is exactly what the permissive servers of the 1990s could not do and what the events of 1994 made unavoidable. Registration is not a business model on a text-only service; it is a liability control, and a fairly minimal one.

Weighing up a server therefore comes down to the same four questions the old list-keepers asked by hand, even though only one of them can still be answered by connecting and looking: which hierarchies does it carry, will it let you post as well as read, how far back does it go, and what does it want to know about you first. The last of those is the one that has changed sides. It used to be the question that disqualified a server from a free-server list; it is now the question whose answer tells you the operator is running the service on purpose.

So the word free has changed meaning on this page. On the lists this page grew out of it meant open to anonymous connections; today it means free of charge, and the two are close to opposites. A server that still answers a stranger without credentials is far more likely to be misconfigured than generous, and the courteous response to finding one is the response the old list-keepers already recommended for the university machines that were open by accident: tell the administrator, and do not publish the address.

The archive is usually the real answer

Most people who arrive at a page called free news servers are not, on inspection, looking for a news server. They are looking for something that was posted — an answer given in a technical group in 1998, a thread they remember from a hobby group, a message written by somebody who has since died. That is a different question from how to read Usenet now, and the sections above have already ruled out the obvious answer to it. Retention is a property of a server; even a generous text-only service holds a slice of the past rather than the past, and no live server anywhere holds the network's history, because no such server has ever existed.

The archives are the instrument for that question, and they are a genuinely different kind of thing: a corpus to be searched rather than a service to be connected to. The largest of them began as Deja News, which started web-based archiving in March 1995 and was bought by Google in February 2001; the collection now reaches back to May 1981, the earliest years of it recovered from tapes that Henry Spencer had kept at the University of Toronto and donated with the help of others at the University of Western Ontario. That archive has been frozen since 22 February 2024, when Google stopped accepting new Usenet content and withdrew its own NNTP server and peering, while leaving what it had already collected readable and searchable. Its coverage is uneven in ways that are documented and worth knowing before you conclude that something is not there. All of that — what the archives contain, how they were assembled, and how to search them without wasting an afternoon — is the subject of the page on accessing Usenet today, which owns it and treats it properly.

The two questions are worth keeping apart in your own head, because the answers have almost nothing in common. To take part in a conversation that is happening now, you need a server, a newsreader and an account. To find something that was said, you need a search interface and a lot of patience with somebody else's indexing. A page that answers only the first question, as this one used to, sends most of its readers in the wrong direction with perfect confidence.

Why this page no longer keeps a list

It would be simple enough to publish a table again. Scanning tools still exist; a scripted sweep could produce a page of addresses that answer on port 119 within an afternoon. The reasons not to are worth stating, since a reader is entitled to know why a page called free news servers declines to list very many.

The first is that an unmaintained list of open servers is worse than no list. Its failure mode is silent: entries do not announce that they have closed, they simply stop answering, and a reader who tries three dead addresses concludes that Usenet is dead rather than that the page is. Every fossil list still online is currently making that argument on the network's behalf, and it is not a true one.

The second is that a maintained list is a maintenance commitment, monthly and indefinite, of exactly the kind that killed the genre the first time. The old list-keepers did not stop because they lost interest; they stopped because the number of servers worth testing fell below the number that justified the testing.

The third is editorial. Recommending services is not what a directory of newsgroups is for. This site's subject is what was posted and where, in some tens of thousands of groups, and the moment it begins ranking commercial providers it acquires an interest in the answer that it cannot then set aside. The two hosts named above this article are inherited from the page's earlier life and are described in one line each precisely so that they read as a pointer rather than a verdict.

And the fourth is the oldest and least respectable: publishing a working address is a reliable way to stop it working. That was true of the university machines in the 1990s and it is true of anything open now. The genre of page this used to be contained, from the beginning, the mechanism of its own extinction.

Scope and limits

What is asserted here comes from documents, and it is worth saying which. The protocol claims are taken from the RFCs themselves rather than from summaries of them: the numbers, titles, authors and dates given above were read from the published texts, and where the specification is relied on for a requirement — the range of article numbers, the eight mandatory overview fields, the 60,000-octet recommendation, the deprecation of MODE STREAM — the wording of the document was consulted directly. One discrepancy is worth flagging rather than hiding: Wikipedia's article on NNTP dates RFC 977 to March 1986, while the document's own title page says February 1986. This page follows the document.

The June 2008 agreement is described from the Attorney General's own announcement of 10 June 2008, which is where the 88 newsgroups, the 11,390 images, the sum of 1.125 million dollars, the NCMEC registry provision and the list of three signatory companies come from; the subsequent conduct of individual providers, and DeJean's market-share observation, are as recorded in the press coverage of the period. The traffic figures are the altopia.com series as tabulated by Wikipedia. The group counts were produced by counting the Internet Systems Consortium's published active file directly on 26 August 2026; they describe the namespace as that file records it on one day, and the file itself is a compilation whose limits are discussed on the newsgroups list page.

Three figures the earlier version of this page carried have been changed rather than repeated, and the reasons belong in the open. Its statement that articles in the late 1980s were often limited to 60,000 characters had the number right and the provenance wrong: 60,000 octets is a posting recommendation from Spencer's Son of 1036, drafted in the early 1990s and published in 2010, sitting alongside a separate 65,000-octet requirement on implementations, and it is given here with that source. Its figures for what the 2008 providers dropped — some eighteen thousand groups in alt.*, roughly three thousand in the Big Eight — could not be re-verified for 2008 from any surviving source, so the present-day counts, which were counted rather than estimated, are given instead. And its statement that the largest commercial services advertise retention of more than twelve years is retained exactly as it stood, because that is the figure a citable source supports; a larger number appears on vendors' own pages, and vendors' own pages are not a source this directory will cite for anything.

Several things are deliberately absent. No server on this page has been tested by this directory: the two named above it are described as they have long been described and are not the product of a fresh survey, and nothing here should be read as a statement about their present condition. No commercial provider is named, ranked or compared — which is also why the earlier version's three named binary services, and its claim that several of the larger operations run from the Netherlands, have not been carried forward; the trade is described as a trade instead. No advice is offered about what to do with a binary feed, which is a subject this directory does not cover at all.

And several things the record does not settle. Whether the 2008 campaign caused the withdrawals or merely dated them is a question the sources raise and do not answer. How many open servers there were at the peak is unknowable, since the population was never enumerated by anyone with an interest in accuracy — the surviving lists are samples taken by enthusiasts, not censuses. When the last genuinely open public server closed is likewise unrecorded, and probably unrecordable: these things do not end with an announcement, but with a firewall rule that nobody outside the building ever hears about.