Summary

  • An NNTP 480 response meant the current command could not be used in the connection's present identity state; it was not a promise to run the command later.
  • After successful AUTHINFO, the client had to inspect the newly available capabilities and issue the original command again.
  • Authentication established a principal, not universal permission: the retried request could still receive 502 under local authorization policy.

The request appeared twice

The revealing transcript is only a few lines long:

C: GROUP local.research
S: 480 Permission denied
... authentication succeeds ...
C: GROUP local.research
S: 211 Group selected

The repeated GROUP is not redundant ceremony. Between the two requests, the server learned something new about the connection. It did not keep the first command in a private waiting room. It did not interpret a valid credential as permission to execute whatever had most recently failed. The first request ended with 480; the second began after identity state had changed.

That distinction is easy to miss because human interfaces often turn the sequence into one gesture: click a protected resource, sign in, arrive at the resource. NNTP's wire protocol exposed the three separate acts. The client asked. The server refused under current conditions. The client established identity and then chose whether to ask again.

Running practice made retry explicit

RFC 2980 recorded the common NNTP extensions that had accumulated around the original protocol. Its description of the installed-base AUTHINFO USER and AUTHINFO PASS commands is unusually direct. When authorization was required, the server returned 480. The client supplied a user name, possibly received 381 for a password, and obtained 281 if the combination was accepted. The next step was not server-side continuation: the client should retry the command that had received 480, and the server would process that new attempt normally.

The wording preserved ownership of intent. Credentials answered “who is this connection presenting?” They did not answer “does the client still want the earlier operation?” A user could abandon the request after seeing the authentication method, a client could discover that the protected operation was no longer relevant, or the connection's advertised functions could change while identity was established. Reissue made current intent observable.

The old mechanism had a grave weakness. RFC 2980 stated that all authentication information was passed in cleartext. A retry boundary did not make the secret safe. It only kept the rejected resource command separate from the credential exchange. Protecting the credential required another layer.

Formal authentication did not absorb authorization

RFC 4643 later formalized USER/PASS, deprecated the old SIMPLE and GENERIC variants, and defined a SASL profile for NNTP. It begins with a governance boundary: AUTHINFO authenticates a user, while authorization remains a matter of site policy. The server decides what an authenticated principal may do according to local configuration.

This separation gives 480 a precise but limited meaning. A client must authenticate and/or obtain authorization before using the command or resource. Authentication may make the facility available, which is why the condition is recoverable. It does not guarantee success. RFC 4643 contrasts that state with 502, which can say that a resource remains unavailable even after authentication.

The difference prevents a common evidentiary error. A successful 281 proves that the server accepted an authentication exchange for this session. It does not prove membership in every restricted group, permission to post, permission to use a peer-transfer command, authorship of any article, or authority over content already stored elsewhere.

Capabilities belonged to a moment in the session

Before attempting AUTHINFO, a conforming client should ask for CAPABILITIES. The returned authentication forms and SASL mechanisms describe what is available in the connection's current state. They may differ after TLS is established, after the user authenticates, or after the server changes mode.

RFC 4643 makes the post-authentication change visible. Once authentication succeeds, the server must stop advertising AUTHINFO, reject another AUTHINFO attempt with 502, and may change other advertised capabilities. A restricted command or newsgroup can become visible only then. The client therefore needs a fresh capability view before deciding what to retry.

One item deliberately remains for comparison: the server continues advertising the same SASL mechanism list after authentication. That lets a client detect evidence of an active down-negotiation attempt. The list is not an invitation to authenticate twice; it is a stable observation against which the earlier negotiation can be checked.

Capability discovery was consequently neither a static product sheet nor an eternal server property. It was a statement about one connection at one stage. Replaying the old command automatically would risk evaluating it against a capability surface the client had never observed.

Authentication itself had a state machine

AUTHINFO was not a bag of interchangeable credentials. A client could begin after 480, or proactively when the capability was advertised, but it could continue beyond the first authentication step only when a 38x response invited continuation. Any other reply ended the exchange. The server could not answer AUTHINFO itself with 480, because that would create an authentication demand that authentication could never satisfy.

The legacy 381 response is particularly instructive. It does not mean “continue this same command with more data” in the ordinary NNTP sense. It instructs the client to send the distinct AUTHINFO PASS command. RFC 4643 preserved that historical sequence while warning that USER/PASS should not be exposed without a strong encryption layer unless backward compatibility forced the risk.

After success, a second authentication attempt was forbidden in the session. Identity transition was designed as a one-way boundary. If software wanted a different identity, it needed a new connection rather than silently replacing the principal underneath outstanding work.

Privacy was a separate recoverable condition

NNTP also assigned 483 to a different problem: the connection needed appropriate privacy protection. RFC 4642 defined STARTTLS for that transition. After TLS negotiation, application state had to be rebuilt and capabilities queried again. Mechanisms such as cleartext USER/PASS might appear only inside the protected channel; other mechanisms could disappear.

That sequence shows why a single “login” concept is inadequate. TLS protects a link. AUTHINFO establishes an identity in the NNTP session. Site policy authorizes particular resources. Reissuing GROUP expresses current intent. None of those steps automatically supplies the authority of the next.

It also bounds the protection. TLS does not sign the news article, establish its author, or protect every later relay hop. AUTHINFO does not turn the transport credential into a content identity. The retried command remains an ordinary NNTP request subject to the server's current policy.

A refusal was evidence, not deferred work

RFC 3977 provides a compact example: a client asks for a protected group, receives 480, completes an authentication extension, and issues the group command again. This is the operational heart of the design. The response is evidence that the first attempt did not acquire the requested facility under the old state.

For observability, the events should remain separate. An operator should be able to see the original command, its 480, the authentication mechanism offered, the protected or unprotected channel state, the authentication result, the post-authentication capability set, the explicit retry, and the final resource decision. Combining them into a single “login succeeded” log entry destroys the evidence needed to diagnose loops, unintended replay or overbroad authorization.

The retry may be identical in syntax, but it is not identical in context. It arrives later, under a different principal and possibly a different set of extensions. It can succeed, fail permanently, fail temporarily for another reason, or be omitted because the client changed its mind.

Registration kept the authorities separate

The IANA NNTP Parameters registry lists AUTHINFO, SASL and STARTTLS as distinct capabilities, each with its own defining RFC. That common vocabulary allows implementations to describe the available transitions without collapsing them.

Registration proves no account entitlement. It says nothing about whether a particular server offers a mechanism now, which groups a principal may read, or whether a deployment still permits USER/PASS. The capability response from the current connection and the final command response remain the relevant evidence.

The architectural lesson is broader than NNTP. Whenever a system asks for stronger identity after rejecting an operation, it must decide who owns replay. Giving replay to the client makes renewed intent explicit and lets the client observe changed conditions. Giving it to the server can turn a credential success into an invisible authorization to execute stale work.

NNTP chose the first model. The user could become known without the discarded command becoming alive.

Sources