Accessing Usenet today

Long-form reference · 8,888 words · about a 39-minute read

What you are actually connecting to

Usenet is not a site you visit. It is a set of independent servers that exchange messages with one another, and it is reached the way e-mail is reached: with an account on one server and a program on your own machine that knows how to talk to it. There is no home page, no central sign-up, and nothing to join. If you have arrived here from one of the group pages in this directory and want to read the group rather than read about it, the whole of the practical answer is three nouns and one decision.

The three nouns are the server, the newsreader and the group. A server is a machine that holds articles and hands them out on request; you need an account on exactly one, and which one you pick decides what you can see. A newsreader is a program running on your own computer that keeps your subscriptions and your read marks locally and fetches articles from the server as you ask for them. A group is a name written in dotted segments from the general to the particular, and an article is a plain-text message with a block of headers at the top — an e-mail addressed to a subject rather than to a person.

The decision is whether you want the live network or the archive. They are different things, reached by different means, and confusing them is the commonest way to conclude that Usenet is dead. The live network is what is being posted now: the articles your server received in the last few days or weeks, in the groups that still move. The archive is what was posted between 1981 and 2024, most of it in groups that no longer carry anything, and no live server holds it. Retention on a text server is measured in months, not decades: Eternal-September, the server this page recommends below, publishes its own figures as three years for the German hierarchy, 160 days for the Big Eight, 130 days for alt.* and 90 days for everything else. If you are here because you remember a thread, or because a group page in this directory described a conversation you want to read, the archive is your answer and you can skip to it below. If you want to say something to somebody, you need a server.

This page is the how. What Usenet is, where it came from, how the hierarchies were named and why alt.* exists at all are the subject of what Usenet is, and none of that is repeated here beyond what an instruction needs to make sense. Everything below was checked against live services and primary documents on 28 August 2026; where something could not be checked, the text says so.

The protocol underneath: NNTP and its specifications

Everything a newsreader does over the wire is NNTP, the Network News Transfer Protocol. It is a line-oriented text protocol of the same family as SMTP and IMAP: the client sends a short command, the server answers with a three-digit response code and, where appropriate, a block of lines terminated by a line containing a single full stop. You can drive it by hand from a terminal, and people learning it usually do once, which is a good way to discover that there is very little to it.

Four documents carry the weight, and it is worth separating them because implementations still offer choices that only make sense once you know which document a choice comes from. RFC 977, written by Brian Kantor of the University of California, San Diego and Phil Lapsley of the University of California, Berkeley, was published in February 1986 and defined the protocol. RFC 2980, an informational memo by S. Barber of Academ Consulting Services published in October 2000, wrote down the pile of extensions that had grown up around it in the intervening fourteen years without ever being standardised. RFC 3977, by C. Feather of THUS plc, appeared in October 2006, obsoleted RFC 977, updated RFC 2980, and remains the current specification. Alongside it, RFC 5536 and RFC 5537 — both dated November 2009, and both obsoleting the old RFC 1036 — define what an article looks like and how servers are supposed to treat it.

Transport security arrived in two instalments and left two habits behind. RFC 4642, of October 2006, formalised a STARTTLS command so that an ordinary session on port 119 could be upgraded to TLS in place, and explicitly discouraged the older practice of dedicating a separate port to encryption. RFC 8143, of April 2017, reversed that advice: it updated RFC 4642 to record that port 563 is registered with IANA for NNTP over TLS, that implementations using it begin the TLS negotiation immediately on connection, and that this immediate or implicit TLS is what implementations and deployments should now prefer. Both mechanisms remain in service, which is why your newsreader offers you a choice between port 119 with STARTTLS and port 563 with TLS from the first byte. Take 563 unless something prevents it.

There is a third port worth knowing, because you will see it and it is not for you. RFC 3977 says that a host offering separate servers for transit and for reading clients should use port 433 for transit and 119 for readers. Transit is server-to-server: the flow of articles between peers that makes the network a network. Eternal-September, to take the example this page recommends below, publishes its peering address on port 433 and its readers on 119, 563, 80 and 443. If you point a newsreader at a transit port you will get a server that is not interested in you.

Two later extensions round out the set. RFC 8054, of January 2017, defines a compression extension, which matters on slow links and to nobody else; a session opened for this page found Eternal-September advertising it as COMPRESS DEFLATE. RFC 8315, of February 2018, defines the Cancel-Lock and Cancel-Key headers, which are the modern answer to a very old problem — that anybody could once forge a request to delete anybody else's article — and which are discussed under posting below.

The conversation your newsreader is actually having

A reading session is a short list of commands, and knowing them makes the rest of this page legible. CAPABILITIES asks the server what it supports. LIST, in its ACTIVE form, asks for the groups the server carries. GROUP selects one and returns the number of articles held and the range of article numbers they occupy. OVER pulls the overview database for a range of those numbers. ARTICLE fetches one message entire, headers and body. POST hands one back. Nothing is pushed at you: the client asks and the server answers, which is why reading a busy group over NNTP is instant on any connection that can carry e-mail.

OVER is the command that makes a newsreader feel fast, and RFC 3977 fixes exactly what it returns. The first eight fields must be, in order: the article number, then the contents of the Subject, From, Date, Message-ID and References headers, then two metadata items giving the article's size in bytes and its length in lines. Everything you see in a threaded article list before you have opened anything — subject, author, date, size, and the thread structure itself — comes from those eight fields, fetched for a whole range of articles in one round trip. Servers may offer further fields, and LIST OVERVIEW.FMT tells a client which; on the server tested for this page the ninth field is the cross-posting record, Xref.

LIST ACTIVE returns four fields per group: the name, the high and low water marks, and a status character. The status is typically y for posting permitted, n for posting not permitted, and m for a moderated group, where your posting will be mailed to a moderator rather than injected into the network. The specification says other values may exist, that they may be private to a particular server, and that a client should treat an unrecognised status as giving it no information. If your reader shows you a group you cannot post to, this field is usually why.

One consequence of all this catches every newcomer eventually. Your subscriptions are not held on the server. They live in a file on your own machine — historically called .newsrc, and still called that by several of the terminal readers — along with the record of which articles you have read. Change newsreader and you lose them unless you copy the file across; change server and you keep them, because they were never anywhere else. The server knows your account and your password. It does not know what you read.

Authentication, and why a free server wants an e-mail address

The commands that identify you are AUTHINFO USER and AUTHINFO PASS. Like much of NNTP they were common practice long before they were a standard: RFC 2980 described them in October 2000, and RFC 4643 standardised them in October 2006, the same month as the protocol revision itself. Your credentials cross the wire in the clear unless the session is encrypted, which is the practical argument for port 563 rather than a theoretical one.

Registration on a free text server is not a business model; it is a liability control, and the history of why is told on this directory’s free news servers page, which owns it. What matters here is a configuration trap that costs more first-time users an evening than any other single thing. Several clients will not send credentials unless told to, on the reasonable assumption that a server which answers without them does not want them. A server that offers a small number of groups to anonymous connections and everything else to authenticated ones will therefore show such a client the small number of groups, with no error and no explanation.

This is not a hypothetical. Opening an unauthenticated TLS session to Eternal-September while writing this page and asking it for its group list returned exactly ten groups, all of them in the server's own eternal-september.* hierarchy, which is open to unregistered users for testing and support; asking the same session for the alt.* groups returned an empty list rather than an error. That is precisely what a misconfigured client sees, and the operator documents the case for the same reason.

The fix is to find the setting in your client that forces authentication. In Thunderbird and SeaMonkey it is a checkbox in the server settings, worded as always requesting authentication when connecting to this server; in Gnus it is a line in the authinfo file with the force flag set; in tin it is an entry in a .newsauth file in your home directory, readable and writable only by you, with the program started using its authentication switch; in slrn before version 0.9.9 it was a force-authentication line in the configuration file. Having fixed it, you must also make the client fetch the full group list again, because from its point of view the groups it now has permission to see are not new groups, and it will not ask for them unaided.

What a server carries, and why two servers differ

Each server carries the hierarchies its operator has chosen and exchanges articles with the peers its operator has arranged. There is no master list and no authority that can add a group to your server without your administrator's consent. When you post, your server injects the article and propagation carries it outward through its peers, typically reaching the rest of the network within minutes. When somebody else posts, the reverse happens, and whether the article reaches you depends entirely on whether the chain of peers between you carries that group.

Group creation and removal travel as control messages: ordinary articles whose Control header asks every server that receives them to create or remove a group. Each server decides for itself whether to obey, and the decision is written in a configuration file — in the widely used INN server, control.ctl. The Internet Systems Consortium publishes a shared version of that file, and reading it explains the character of the namespace better than any prose. For the Big Eight, it drops every newgroup and rmgroup message by default and honours only those cryptographically verified against the key of the moderated group news.announce.newgroups. For alt.*, it accepts newgroups from anybody at all and silently ignores every rmgroup, and the file's own comments strongly recommend that a small site change that policy to drop alt.* control messages entirely and add groups only when a user asks, on the grounds that great numbers of alt.* newgroup messages are sent out with the intent of creating nonsense entries in other people's active files rather than a usable newsgroup.

That difference is visible in numbers. The aggregated newsgroups file the Internet Systems Consortium publishes, in the copy retrieved while this page was written and stamped 28 August 2026, lists 1,898 groups across the Big Eight — 677 in comp, 659 in rec, 213 in soc, 185 in sci, 100 in misc, 31 in talk, 26 in news and 7 in humanities — of which 99 are flagged moderated. It lists 20,466 groups under alt.*. The Big Eight namespace is small, governed and audited; alt.* is large, ungoverned and full of names nobody has ever posted to.

Now compare a real server. On 28 August 2026 the hierarchies page of Eternal-September listed 281 hierarchies and 26,190 groups. Its Big Eight counts were 677, 659, 213, 185, 100, 31, 26 and 7 — identical, group for group, to the ISC file. Its alt.* count was 8,728 against the namespace's 20,466, and searching its group list for alt.binaries returned twenty-seven names, nearly all of them holding no articles at all. That is the whole shape of modern text Usenet in one comparison: a well-run free server carries the entire Big Eight and every national hierarchy you are likely to want, declines most of alt.* as junk, and does not carry the binaries in any meaningful sense.

The reason is that one protocol carries two unrelated businesses. Discussion in plain text is cheap to move and cheap to keep. The binary hierarchies, where files are chopped into article-sized pieces, encoded as text and reassembled by the recipient's software, are a storage industry, and the retention-in-days and completion percentages the commercial providers advertise measure that industry rather than this one. The two rarely share an operator. Eternal-September's published peering configuration excludes the binaries branches from what it feeds outward, and its terms of use forbid posting binaries to groups that do not explicitly allow them. For the historical arithmetic behind that split, see this directory’s free news servers page.

The last thing that differs between servers is what they throw away. Spam filtering is not an optional refinement on a modern text server; it is the difference between a readable group and an unusable one. Eternal-September's published description of its own arrangements is a fair example of what competent filtering looks like: articles are screened by Cleanfeed using a custom SpamAssassin ruleset, articles marked as spam are saved and then rejected, a cron job every fifteen minutes turns the saved articles into a NoCeM notice — a signed message telling other servers what one operator considers spam — and posts it to news.lists.filters, and the server in turn honours NoCeM notices from five other named issuers. When two servers show you the same group and one of them looks dead while the other looks merely quiet, this is usually the reason, and the difference runs in both directions: over-aggressive filtering silently removes real articles too.

Getting an account: the standard free route

The usual first stop, and the one this site has recommended for years, is Eternal-September: a free, registration-required, text-only public server based in Germany. It was checked from scratch on 28 August 2026 before being recommended here, and the check went further than reading the web site. The domain resolves; the site answers over HTTPS and its pages carry modification dates in 2026; the operator's own status page lists five services — a feeder on port 433, the reader on 119 and on 563 with SSL, and two further readers on ports 80 and 443 for people behind firewalls that block the news ports; and the site's news panel carries an operational notice dated 22 December 2025 about disposable-address abuse in registration.

The server itself answers. Connecting to port 563 from an ordinary machine, the TLS handshake completes and the banner reads that this is an InterNetNews NNRP server, INN version 2.8.0, ready, posting ok; CAPABILITIES reports AUTHINFO USER, COMPRESS DEFLATE, HDR, LIST, OVER, POST, READER and XPAT. A plain connection on port 119 gives the same banner. That is a live session rather than a claim taken from a status page, and it is the only part of this page that could go stale between writing and reading.

What the operator's technical page gives you is the entire client configuration, and it is short. The server name is news.eternal-september.org. The port is 119 for a plain connection or 563 for an encrypted one. Alternative reader names exist on ports 80 and 443 for constrained networks. Concurrent connections are limited to four, which matters only if you run a reader that likes to open many at once. You register through a form on the site with a real, deliverable e-mail address — the credentials are sent to it immediately, and an account whose registration mail is undeliverable is deleted automatically, so a disposable address will not do; a number of disposable-address providers are blocked outright.

Read the terms before you post, because they are unusually specific and they are the house rules of the machine you will be injecting through. The From, Reply-To and Sender addresses should be ones you are entitled to use and should not bounce, though the reserved top-level domain invalid may be used in From to defeat address harvesting — a convention you can watch working in any live group, where a good half of the addresses end in it. No spam. No binaries in groups that do not explicitly allow them. No article larger than 1000 KB. No control messages except cancels and supersedes for your own articles, plus two hierarchy-specific exceptions. No cancelling anybody else's article. No sharing your account. German law applies, since that is where the server is.

One inconsistency is worth flagging rather than glossing, because it affects whether your account still exists when you next want it. The terms of use state that accounts are deleted automatically after 180 days of inactivity, with an e-mail warning 30 days beforehand; the FAQ on the same site states 18 months. Both pages were read on 28 August 2026 and they do not agree. The safe reading is the shorter one: connect with your credentials every few months and the counter, whichever counter it is, resets.

There is a diagnostic worth memorising for the first evening. If you connect successfully but can only see a handful of groups whose names begin with the server's own hierarchy, you have not failed to register — your client is not sending your credentials. Go back to the previous section.

The other routes, and what has gone

Eternal-September is not the only way in, and a page that pretended otherwise would be doing the same thing as the fossil server lists it is trying not to become. But the honest survey is short, and it is shorter than it was.

University and institutional servers. These were once the normal way to read news, and the namespace still remembers them. The Internet Systems Consortium's control file carries entries for individual universities’ own hierarchies, with a named contact address for each; the hierarchy list of a single free server includes trees belonging to particular universities, national research networks and laboratories. A hierarchy surviving in a list is not the same as a server you can connect to, and most of the machines behind those names are long gone. The rule remains worth applying, though, because when it works it works well: if you are at a university or a research institution, ask whether there is a news server, and ask a systems administrator rather than a help desk. Institutional servers that survive tend to be unadvertised, well-run and generous to their own community.

Internet service providers. As a category, effectively gone. The bundled news server that every free-server list once assumed would be there as a fallback became the exception during the late 2000s, in a sequence of withdrawals with specific dates and specific causes that is set out in full on the free news servers page. If your provider still offers one, it will be listed in your account settings; almost none do.

Paid providers. A real and functioning market, and mostly not for you. What the commercial providers sell is the binary trade: retention measured in thousands of days, completion percentages, many simultaneous connections, and the storage capacity to back all three. A text reader gains almost nothing from any of it, since the limiting factor on reading a discussion group is not how much the server keeps but whether anybody is posting. Some providers offer inexpensive text-only tiers, and a cheap account is worth considering if you want a second, independent server as a check on the first. This directory does not rank them, name them or link them, for the reason given on the free-server page: the moment a newsgroup directory starts recommending commercial services it acquires an interest in the answer.

What has gone. Two absences deserve naming, since both were standard advice within living memory. AIOE was for many years the other public server every list gave, notable for allowing posting without registration; its domain no longer resolves — checked again on 28 August 2026, with no address published for the domain or for its news host — and this site has removed it from its own free news servers page accordingly. And Google Groups, which for two decades was the way most people posted to Usenet without ever installing anything, stopped accepting Usenet postings in February 2024. Those two removals are most of the reason this page had to be rewritten.

Web front ends. Reading Usenet through a browser is a real option — Eternal-September links a browser client of its own from its front page — and it is the right answer for a reader who wants to look at one group once. The subject belongs to web-based ways to read Usenet, which covers it properly.

Choosing a newsreader

A newsreader is a client in the same sense a mail program is. It keeps your subscriptions, your read marks and your filtering rules on your own machine and speaks NNTP to whichever server you point it at. The list of things worth insisting on is short and has not changed in thirty years. It should build threads. It should remember what you have read between sessions. It should let you suppress articles by author, subject and pattern. It should compose in plain text and let you trim a quotation by hand. And it should handle character sets honestly, because the older groups are full of articles written before anyone had settled how to declare an encoding.

The difference between such a program and a web view of the same articles is not cosmetic. A web archive shows a group as pages of messages, flattened or shallowly nested, with no memory of what you have seen and no way to suppress what you do not want; it is a search interface over a corpus. A reader builds the discussion tree from the References header of each article, so a fifty-message argument arrives as a shape you can navigate: collapse a branch, follow one line of reply, mark the rest read and move on. On a large group the two are not comparable.

What follows is not a ranking. It is a list of programs whose current state was checked at source on 28 August 2026, with what each is good for and what its maintenance actually looks like — because on a page like this a recommendation that has quietly died is worse than no recommendation.

Graphical, cross-platform

• Thunderbird. The default recommendation for most people, because it is a mail program that also speaks NNTP, it runs on Windows, macOS and Linux, and somebody else has already installed it. Very much alive: version 154.0 was released on 18 August 2026, with a long-term-support line at 140.14.1, and the 154.0 release notes list a fix to the handling of expired newsgroup articles — which is to say that the newsgroup code is still being maintained rather than merely shipped. Set it up as a Newsgroup account, not a mail account, and remember the authentication checkbox.
• Betterbird. A fine-tuned fork of Thunderbird, tracking it closely; release 153.1.0esr-bb7 is dated 18 August 2026. Worth knowing about if a specific Thunderbird behaviour annoys you.
• SeaMonkey. The surviving descendant of the old Mozilla suite, browser and mail and news in one window, at version 2.53.24. Dated by design, and the news component works.
• Pan. The dedicated news client of the Linux desktops, and the one to install if you want a program that does nothing but read news: three panes, a score column, and a usable filtering language. Release 0.165 is dated 16 January 2026 and its repository carried commits on 1 August 2026.
• Claws Mail. A light GTK mail client that speaks NNTP alongside ordinary mail; version 4.4.0, released 9 March 2026.

Terminal

• tin. The most actively maintained newsreader of any kind that this page found. Stable release 2.6.6 is dated 23 August 2026 — five days before this section was written. Threaded, fast, entirely keyboard-driven, and it will read from a local spool as happily as from a server.
• slrn. Excellent, small, and honest about its own state: the project's own site records that the current release is 1.0.3a from 2016 and strongly encourages users to run it. That is dormancy rather than abandonment — it is packaged by every major distribution and it works — but do not expect changes. Its scoring system is the best reason to choose it.
• Gnus. The newsreader inside GNU Emacs, documented as part of the Emacs manuals and maintained with Emacs. If you already live in Emacs this is the obvious choice and everything below about killfiles will feel underpowered to you. If you do not, this is not the place to start.
• NeoMutt. The maintained fork of the mutt mail client, with NNTP support built in rather than patched on: it takes a server from the NNTPSERVER environment variable or from a system file, and keeps subscriptions in a newsrc file of its own. Releases are date-stamped and frequent; the most recent found was 16 June 2026.

Platform notes

On Windows the position is that Thunderbird is the sensible answer and the specialist shareware of the 1990s is a museum. Forte Agent, the best known of them, is still sold as version 8.0 from its vendor's site, but the most recent news item on that site is the release of Agent 8 in October 2014; buy it for nostalgia, not for support. On macOS the picture is thinner still: the dedicated Mac newsreaders of the 2000s have mostly gone, and the domain of the best remembered of them now resolves to a domain-registrar parking page, checked on 28 August 2026. Thunderbird, or a terminal reader installed through Homebrew, is the practical answer. On Android and iOS there is no client this page is willing to name, because none could be verified as maintained; the honest advice for a phone is a web front end.

Threading, scoring and the killfile

Three features do all the work of making a group readable, and it is worth knowing what each one actually is rather than where its menu item lives, because the menu item moves and the mechanism does not.

Threading is reconstructed by your newsreader from the articles themselves. Every article carries a Message-ID that is unique across the whole network, and every reply carries a References header listing the message identifiers of the articles it descends from. From those two headers alone a client can rebuild the entire shape of a discussion without asking the server anything further — which is why threading works identically on a group you have just subscribed to and on an article from 1993, and why it survives articles arriving out of order or by different routes. Where a client offers to thread by subject line instead, that is a fallback for badly behaved posters, not the real mechanism.

Scoring assigns a number to each article according to rules you write — this author plus a hundred, that subject minus a thousand — and sorts or colours accordingly. It is the more useful half of filtering and the half most people never configure. A score rule that raises rather than lowers is what turns a busy group into a readable one: mark the six people whose posts you always want to see and the rest can arrive in whatever order it likes.

The killfile is the older and blunter instrument: a file of patterns matched against headers, whose effect is that matching articles are never shown to you. The feature was first implemented in Larry Wall's rn, which is to say it is nearly as old as the medium, and the verb it produced — to killfile somebody — long ago escaped into general use. Every reader named above has one. It is not a moral statement and nobody is notified; it is a local decision about your own attention, and the older regulars regard using it as ordinary hygiene rather than as an escalation. On a modern group where the spam that gets past the server tends to arrive in recognisable batches, a killfile is often the difference between a group and a wasteland.

One further piece of housekeeping belongs here. Mark-as-read is not a formality: on a group whose server holds months of articles, the correct first action after subscribing is to mark everything read and start from now, rather than scrolling backwards through a year you did not ask for. Every reader has a catch-up command for exactly this.

Posting without annoying anyone

Usenet conventions are not decoration. Most of them are compression: they exist so that a reader arriving in the middle of a thread, possibly days later and possibly having missed articles that never reached their server, can tell what is being answered. The netiquette of the medium was written down formally as long ago as October 1995, in RFC 1855, and the parts of it that concern news have aged remarkably well.

• Read before you write. Lurk for a week. This was good advice in 1994 and the groups that survive are smaller and older, which makes it better advice now, not worse.
• Plain text, no HTML, no attachments. Text groups are text groups, and many servers — Eternal-September among them — enforce this in their terms rather than merely requesting it.
• Quote to answer, not to prove you read it. Trim the quotation to the passage you are actually replying to, and reply beneath it, not above. Interleaving your answers with trimmed quotes is the house style and the reason threads remain legible after two decades.
• Leave the attribution line alone. The line your reader inserts saying who wrote what you are quoting is load-bearing; deleting it makes a thread unreadable in the archive.
• Write a subject line that describes the article. It is the only thing most readers will see, and it is also what somebody searching the archive in 2046 will match against.
• Separate a signature with a line containing two hyphens and a space. Clients cut there, and the convention is old enough to be written down: RFC 3676 records “-- ” as the long-standing Usenet separator, and the news article format document Henry Spencer drafted in the early 1990s, published in 2010 as RFC 1849, notes that four lines is a common limit on the length of what follows it.
• Crosspost rarely, and set Followup-To. Posting one article to two or three genuinely related groups is correct and cheap; posting the same article separately to each of them is not, and is close to the technical definition of spam that most server terms use.
• Test in a test group. misc.test and alt.test exist for this. The description the ISC namespace file gives misc.test is, in full, that it is for testing of network software, and very boring.

Two mechanical points that surprise people. The first is that there is no edit button, and the withdrawal mechanisms are weaker than they look. A cancel control message asks servers to remove an article; RFC 5537 puts it that a serving agent which elects to honour a cancel should make the article unavailable, and a great many servers elect not to, because for decades cancels were forged freely — the specification records that the old requirement for a cancel's From to match the original's had only encouraged cancel issuers to conceal their identity and provided no security. RFC 8315 of February 2018 supplied the real answer, the Cancel-Lock and Cancel-Key header pair, which lets a poster prove that a withdrawal request comes from whoever posted the article. Eternal-September's policy is a good example of where this leaves things: it does not execute cancels or supersedes in general, but it does honour Cancel-Lock, adds one to its users' articles automatically at posting time, and separately whitelists a small number of well-known spam cancellers. Practically: assume that what you post is permanent everywhere, and treat any successful deletion as luck.

The second is that identity is more constrained than the anonymous reputation of the network suggests. Servers now impose limits on how often you may change the address in your From header, because address-hopping is how spammers and the deliberately tiresome evade other people's killfiles. Eternal-September rejects postings with an excessive-nymshifting error beyond three different addresses in twenty-four hours, five in seven days or eight in thirty days, and cancels the account of anyone who ignores the temporary bans and reaches twelve in sixty days. Pick an address and keep it.

Etiquette as the original site set it out, in its own voice, is on how posting worked.

Reading the archive instead: what Google Groups now is

Most people who arrive at this directory are not looking for a server. They are looking for something that was said — an answer given in a technical group in 1998, a thread they half remember, a message written by somebody who has since died. That is a different question with a different answer, and no live server can supply it.

The largest searchable archive is Google Groups, which holds it by inheritance rather than by design. The Deja News Research Service began archiving Usenet in March 1995, founded by Steve Madere in Austin, Texas. Archives of Usenet had existed for as long as the medium had, but Deja News offered a combination of features that was new: it was open to the public, it had a simple web interface, it searched across all the groups it held, it returned results immediately, and it kept messages indefinitely. That combination changed what people thought Usenet was — from a loosely organised and ephemeral conversation into a record that would outlive them, and, as contemporaries noticed at once, into something a person could be searched in. Google acquired the archive in February 2001 and moved it to groups.google.com. By the end of that year the record had been pushed back two decades to 11 May 1981, using material donated through the University of Western Ontario and originating in tapes kept at the University of Toronto.

What changed on 22 February 2024 is worth stating in Google's own terms, because the change is precise and it is routinely misdescribed in both directions. From that date, Google Groups can no longer be used to post content to Usenet groups, to subscribe to Usenet groups, or to view new Usenet content; Google's NNTP server and its associated peering were withdrawn, so it neither serves new Usenet content nor exchanges content with other servers. And, in the same notice: historical Usenet content posted before 22 February 2024 can still be viewed and searched. The archive is neither gone nor unchanged. It is frozen — a window onto the record up to early 2024, which is precisely what a Google Groups link from any page of this directory is.

The notice also advised departing users to find a new client and a new server, and added that because Usenet is a distributed system they did not need to migrate any data, since all the Usenet content available to them on Google Groups should already be synced to whichever server they chose. That last sentence is the one place where the notice is simply wrong, and the error is the one this page opened with: no live server holds decades of history, and the reader who followed that advice found a server with months of retention and concluded that the archive had been deleted.

Searching the archive without wasting an afternoon

The single most useful thing to know is that searching within one named group works far better than searching across everything. This is not folklore. Google withdrew the advanced search page that had allowed searches across all groups; it broke the Groups search function in 2008 and left it non-functional for about a year, until press coverage prompted a repair; and on 13 February 2015 a reported investigation found that advanced search across all groups had stopped working again, while, in the words of the researcher quoted, advanced searches within specific groups appeared to be working. The interface has been rebuilt several times since and the asymmetry has survived every rebuild.

In practice that means starting from the group, and the address form is predictable enough to type: the group's name appended to the Google Groups per-group path, groups.google.com/g/. From inside a group, the techniques that pay are these.

• Exact phrases. Quotation marks around a distinctive string outperform topical keywords by a wide margin. An error message, a program name, an unusual turn of phrase or a misspelling that a particular poster habitually made will find a thread that a subject-shaped query never will.
• Author. Names and addresses in the From header are good keys, because Usenet posters were consistent about them for years at a stretch. This is also the search that raised the privacy objections of the late 1990s, and the one most affected by the removals described below.
• Date range. Useful mainly for cutting a large group down, and unreliable at the edges: articles carry the date their poster's computer claimed, clocks were wrong, and some early material was reconstructed from tapes rather than received live.
• Subject line. If a thread appears truncated, search again on its exact subject. Long threads frequently surface in pieces under slightly different threading, particularly where a subject line was changed mid-discussion in the traditional manner.

Then the limits, which are real and which a researcher should know before concluding that something was never posted. Articles whose authors set the X-No-Archive header were never archived at all. Deja News offered posters a facility to remove their own messages permanently — nuking — and although the facility was withdrawn under Google, nukes already in effect are still honoured. Copyright holders could have material removed, and did. Since May 2014 European residents have been able to request that search results for their names be delinked under the right to be forgotten, and as of 2015 Google Groups was among the ten most delinked sites. And the archive has a structural wound in the middle of its life: when Deja.com changed direction in 1999 and moved its servers, many older messages became unavailable and never came back. An absence in Google Groups is evidence of very little.

The Internet Archive, and keeping a copy

The Internet Archive's Usenet holdings are the opposite instrument, and the complementary one: not a search interface but a corpus you download. The Usenet Historical Collection was created there on 21 January 2014, described in its own metadata as spanning more than thirty years and as having been given by a generous donor; on 28 August 2026 it contained 1,019 items. The items are organised by hierarchy, and each contains one compressed mailbox file per group. The soc item, to take a representative example, holds 341 per-group mailbox archives amounting to a little over thirty gigabytes. Around that collection sits a much larger and looser one — some seventy-nine thousand items when counted on the same day — which includes a series of 52,800 per-group mailbox files, one per group and each labelled with the number of articles it holds, captured from a full feed in October 2020.

There is no comfortable per-message browsing and there is no search box. What you get instead is the thing an archive is actually for: complete articles with their headers intact, in a standard format, which you can grep, load into a mail client, or run a script over. The files are what the contributing servers held, gaps and typographical errors in group names included, which makes them the better source for anything systematic — counting, sampling, tracing a conversation across groups — and the far better source for anything that must still exist in a decade. In practice the division of labour is simple: Google Groups to look a thing up, the Internet Archive to keep a copy.

Reading a downloaded mailbox needs no special software. Most mail clients will open one directly; on a Unix-like system, decompressing the file and searching it with grep for a phrase, an address or a Message-ID is usually faster than any interface, and the From lines that separate messages make it trivial to count what you have.

The UTZOO tapes, and how the record was assembled

The shape of the archive's gaps is explained by its lineage, and the earliest stretch of it exists because of one person's filing habits and another's pickup truck.

Henry Spencer ran the computer system of the zoology department at the University of Toronto, and in 1981 acquired a Usenet feed from Duke University and brought its machine, utzoo, online. An earlier Canadian site had taken news that year as a read-only medium; utzoo was the first active Usenet site outside the United States, and the earliest public archives of Usenet date from May 1981 as a result. Between 1981 and 1991 Spencer copied more than two million Usenet messages onto magnetic tape, simply keeping them. Whether anyone could get at them was raised at a Usenix conference in the early 1990s, and the honest answer was that he had neither the disk space nor the tape drive to pull them down.

What happened next is documented by one of the people who did it, in a note by David Wiseman dated 11 December 2001 and preserved with the collection. Wiseman, at the University of Western Ontario, did have the equipment; he drove the two hours from London to Toronto, collected 141 magtapes from the zoology department and brought them back — an operation he summed up with the old line about never underestimating the bandwidth of a pickup truck on the highway. The tapes were read onto disk at Western Ontario's computer science department and at a research institute nearby, with help from several people including a colleague from the University of California, San Diego who spent a week of his vacation on it. Then the project stalled for years: people moved on, the vacation ended, disks ran out. Brewster Kahle of the Internet Archive pushed intermittently and bought a large disk. Google pushed in the summer of 2001, a student was hired to do the final sorting, and the collection was made available to Google in the middle of October. It appeared in Google's archive that December, which is how a service launched in 1995 came to hold articles from May 1981.

The tapes were later placed at the Internet Archive as an item of their own, and they are not there now. In 2020, after sustained legal demands that a set of messages within the archive be redacted, the Archive removed the files rather than either edit them or keep contesting the demands — its own note gives both reasons, the further cost and the wish to avoid accusations of manipulation. What remains at that address is a file listing and a set of checksums, published so that anyone holding a copy can verify it against the original. The listing runs to 161 entries: one file for each of the 141 tapes, nineteen continuation files for the tapes that would not fit in one, and a final file of scavenged material. The sizes run from 1.4 to 65 megabytes, and along the main sequence they climb steadily from about five megabytes at the start to forty-odd at the end — the growth of Usenet itself, visible as a column of numbers.

Two seams follow from all this and they explain most disappointments. The tapes stop in 1991 and Deja News starts in March 1995, so the early nineties depend entirely on whatever else was donated later. And the pre-1991 material was recovered from one site's feed, which means it holds what Toronto received, not what the network sent.

What to expect when you get there

The text hierarchies are much smaller than they were and reports of death remain premature. What survives is best described honestly, and it can be described with numbers rather than impressions, because at least one server publishes its own.

Traffic concentrates, and it concentrates in places a 1997 reader would not entirely have predicted. Eternal-September publishes a monthly count of the articles its own users post, broken down by hierarchy. For August 2026 the order runs: alt with 8,048 postings, then it with 4,924, de with 3,355, comp with 3,058, rec with 2,923, uk with 2,543 and fr with 2,073, followed by sci at 835, nl at 827 and pl at 768, and a long tail below that. Read the figures for what they are — the traffic of one free text server's registered users, not of the network — and they still say something no impression can: that the alternative hierarchy and the national trees, Italian, German, British, French, Dutch, Polish and Finnish among them, carry a great deal more discussion than the English-language Big Eight does.

The same statistics name the groups, and the named groups are the real answer to what survives. In that month the busiest were alt.buddha.short.fat.guy with 1,848 articles and it.test with 1,362 — a testing group, which tells you something on its own — then alt.fan.rush-limbaugh, it.politica and de.talk.tagesgeschehen, and after them a recognisable spread of ordinary subjects: uk.railway, rec.arts.drwho, fr.rec.photo, rec.arts.tv, uk.d-i-y, sci.electronics.design, nl.politiek, alt.usage.english, rec.food.cooking, comp.os.linux.misc, comp.lang.c, rec.arts.sf.written. Several hundred other groups stand silent, and a further set carry nothing but the spam that got past the filters. The distribution is severe, and it is easy to sample: a search of the same server's group list for comp.unix on 28 August 2026 returned twenty-nine groups, of which twenty-one held no articles at all and the busiest, comp.unix.shell, held twenty-three.

Governance, remarkably, still functions. The Big-8 Management Board — the body that took over group creation and removal when the old mass votes were retired — has met approximately weekly by videoconference since April 2020 and had published twenty-eight sets of minutes for 2026 by 28 August. Its public record shows exactly the kind of work you would expect of a maintenance crew: a second Request for Discussion posted on 27 August 2026 proposing the removal of a moderated group, another pair in July and August for a second moderated group, a notice in June that a moderator had been found for a group that had lacked one, and, in the minutes of that August meeting, a misformatted proposal rejected by the moderation system of news.groups.proposals, a moderation relay wrongly reported for spamming, and a bounced e-mail chased down by hand. Ninety-nine Big Eight groups are still flagged moderated in the namespace file.

The most instructive item in that record is a set of results published on 2 April 2026. The board had proposed removing five long-dormant comp.unix groups — one of them with no activity since 2009 — and after a discussion period and a last call for comments, all of them were kept. The formal vote in each case was one in favour of deletion, one against, one abstention and one member not voting, which is a very Usenet way to decide nothing and a perfectly good way to leave a group alone. The arguments recorded against removal are the ones worth carrying away: that removing unused groups does not increase participation anywhere else; that many sites will not list a group once it has been removed, so its history becomes hard to reach for anyone who does not already know it existed; and that there is little point tidying a namespace for the benefit of newcomers who are not arriving. That is neither a dead network nor a healthy one. It is a small, elderly institution taking care of its records.

The manners you will meet are the ones described above, held by people who have often been in the same group since the 1990s. Threads move at the pace of days. There are no accounts beyond your server login, no likes, no reactions, no notifications and no edit button. There are no images, and posting one in a text group will get your article rejected before it is read. What there is instead is the thing the format was for: long, cited, unhurried argument, in which somebody occasionally answers a question you asked with a paragraph they clearly spent twenty minutes writing.

How this directory relates to the live network

One caution belongs at the end, because it is the commonest misreading of this site. news2mail.com preserves no messages. Not one article of Usenet content is stored here. What this site holds is a directory: a list of newsgroups drawn from the view a Usenet-to-e-mail gateway had of the network while it ran, from 2000 to 2004, with an editorial description written for each group.

Those descriptions are editorial and historical. They describe what a group was, and the world it belonged to, as far as that can be established from surviving sources. They are not evidence of current traffic in either direction — a lively description does not mean the group is busy today, and a group described as quiet may have found new readers since. The group lists themselves are a snapshot with known limits, discussed on the newsgroups list page; the gateway that produced them, and why the descriptions read as they do, is the subject of the front page.

The live network is a separate thing, and you reach it with the instructions above: an account on a server, a newsreader on your own machine, the group's name typed into the subscription list. Nothing on a page of this directory can do that part for you, and no archive link is a substitute for it, since an archive by definition stops where the live network begins.

The sensible order is to subscribe and look. A description here tells you what a group was for. Only the server can tell you whether anybody is still there.