Summary

  • NNTP's LIST ACTIVE status reported how a server normally handled posts to a group, not a personalized authorization verdict.
  • A group marked y could still refuse the current client, while a privileged client might post to a group marked n; the POST response remained operative evidence.
  • Catalogue visibility, authentication, site authorization, article injection and eventual reader availability were deliberately separate control surfaces.

A permission-looking signal with a smaller job

Imagine a reader opening the server's active-group list. One row ends in y. The interface paints a green compose button. The reader spends twenty minutes writing, sends POST, and receives 440 Posting not permitted before the article body can begin.

Nothing in that sequence requires a faulty server. The fault is in the interpretation. The row described the group. The refusal described this client, on this connection, at this moment.

The reverse case is equally revealing. A row ending in n normally says that posting is not permitted, yet RFC 3977 allows for a client with special privileges to post there. The specification does not define that privilege. It preserves the possibility precisely to stop a catalogue flag from becoming a universal entitlement system.

This is an unusually clean historical example of a recurring Internet design problem: a compact discovery surface is useful only if readers know what kind of truth it carries.

The warning was present from the beginning

RFC 977, published in 1986, defined the LIST response as rows of group name, last article number, first article number and a posting flag. The flag was y or n: posting to the newsgroup was allowed or prohibited.

That sounds personal until the next paragraph. The RFC warned that posting could still be prohibited to a client even when the list said the group allowed it. The group flag existed partly because moderated or digest groups followed a different normal path. It was explicitly independent of the permission the NNTP server granted to a client.

The operative personal decision appeared elsewhere. A connection greeting told the client whether posting was then available. More decisively, POST returned 340 when the server was ready to receive an article and 440 when posting was prohibited for an installation-dependent reason.

The early protocol therefore carried at least two facts that looked similar but served different audiences. The list helped a reader understand the character of a group. The command response told this client whether it could proceed.

LIST ACTIVE sharpened the boundary

RFC 3977 later named the form LIST ACTIVE and made its scope more explicit. Without a filter, the server lists every group the client is permitted to select with GROUP. This is already a local, connection-facing view, not a global map of Usenet.

Each row contains the group name, high and low water marks, and current status on that server. Typical status values are y for permitted posting, n for non-permitted posting and m for forwarding posts to a moderator. An unknown status gives the client no information; private extensions cannot silently borrow the standard meanings.

Then comes the decisive sentence: status indicates how posts to the newsgroup are normally processed and is not necessarily customised to the specific client. A client forbidden to post remains forbidden on a y group. A specially privileged client might post to an n group.

The word “normally” does real architectural work. It turns the row into a statement of baseline workflow rather than a capability token. The list can inform composition and presentation without claiming to have evaluated every account, source address, session mode or local exception.

The actual attempt had its own evidence chain

Under RFC 3977, the server answers POST with 340 before accepting the multi-line article body or 440 when posting is not allowed. After receiving the body, it answers 240 for acceptance or 441 for failure. These stages matter.

A catalogue row is cheap to fetch. A pre-body refusal avoids disclosing a draft. A post-body failure says the server heard the content but did not accept it. Even a 240 does not prove that readers can already retrieve the article; further processing, moderation or transfer may remain.

Compressing those events into one “can post” badge destroys useful evidence. Operators need to know whether the mismatch came from stale group metadata, unauthenticated session state, account policy, body validation, moderation routing or later availability. The protocol gives each boundary a distinct observation.

Authentication could change the client, not the flag's meaning

RFC 4643 formalized NNTP authentication. A 480 response says the client must authenticate and/or authorize before it can use a command or resource. After successful AUTHINFO, the server may advertise a different capability set.

Success still does not mean universal access. RFC 4643 says a server can complete authentication and deny some or all resources; 502 can mark a permanent denial after identity is known. A credential establishes a principal in a session. Site policy decides what that principal may do.

This keeps three claims apart. LIST ACTIVE reports the group's ordinary handling. AUTHINFO records an accepted identity transition. The fresh command response applies current authorization. None can safely stand in for the other two.

The separation also explains why an authorization cache keyed only by group name is unsafe. Identity, transport protection, endpoint and policy may all change while the visible y/n/m row remains identical.

Moderation was a route, not a loophole

The m status completes the vocabulary: posts will be forwarded to the group moderator. It does not authenticate the moderator or promise that an article will be approved. RFC 5537 distinguishes posting agents, injecting agents, relaying agents, serving agents, reading agents and moderators because each holds a different part of the article's journey.

That distinction bounds the present story. A client being allowed to submit does not make it the author of every field. A server accepting a proto-article does not prove downstream relay or reader visibility. A catalogue indicating moderated treatment does not prove who may approve.

The earlier Sofia Ren article on Approved concerns that moderator-authority boundary. Here, m matters only as evidence that the active list describes a normal processing path. The central mismatch remains between group policy and client permission.

Registration preserved separate verbs

The IANA NNTP Parameters registry registers LIST, POST, AUTHINFO and READER as separate capability labels. Registration does not prove that a given server currently offers them, but it supplies interoperable names for distinct functions.

This is not bureaucratic ornament. Discovery, submission, identity and reading can change independently. A client that observes them separately can refresh its model after authentication or mode changes. A product that merges them into one green light risks promising more than the wire has said.

The lasting lesson is evidentiary restraint. A catalogue is valuable because it describes many groups compactly. It becomes dangerous only when a broad description is promoted into a personalized decision. NNTP left the final gate where it belonged: at the actual command, under the actual session, with a response that could be recorded and challenged.

The green light was real. It simply was not yours.

Sources