Summary

  • NNTP POST asked for the article with 340, then returned 240 or 441 only after the complete dot-terminated body arrived.
  • If the connection failed before that final reply reached the client, successful injection and failed injection became indistinguishable from the client side.
  • Keeping the same Message-ID on a later attempt let servers treat the retry as the same intended article, while acceptance, moderation, propagation and reader visibility remained separate states.

The uncertain interval began after the last dot

Imagine a posting client has transmitted every header, every line of body text and the terminating line containing a single dot. The injecting server has enough material to validate the article and commit it. It sends 240 Article received OK. At precisely that moment, the connection disappears. The server has acted; the client possesses no affirmative evidence.

On a clean failure before the body was sent, the remedy would be obvious. Here it is not. Sending the article again may recover a rejected post, or it may create a duplicate of one already accepted. Doing nothing may avoid duplication, or it may silently abandon the only copy. The missing reply has erased the distinction.

This is not merely a transport inconvenience. It is a question of who owns an unresolved intention when one side may have crossed a commitment boundary and the other cannot observe it.

POST always had two answers

RFC 977, published in 1986, defined POST as a conversation rather than a single request. A server first returned 340 if the client should send an article, or 440 if posting was unavailable. Only after the client delivered the complete article did the server issue the consequential result: 240 for success or 441 for failure.

The first positive response was therefore permission to present work, not custody of the work. That distinction mattered to an interactive newsreader. A user might spend time composing before learning whether a server admitted posts at all; RFC 977 even recommended using the connection greeting to warn users about read-only access. But once the upload began, the later response became the only protocol evidence that the article had crossed the posting boundary.

RFC 3977 kept the same shape and made the phases harder to confuse. POST could not be pipelined. 340 and 440 answered the command itself; 240 and 441 came after the article and its termination sequence. A client had to wait for the body verdict before treating the attempt as complete.

Acceptance was a promise about processing, not visibility

RFC 3977 gave 240 a deliberately prospective meaning. Barring unforeseen server errors, the accepted article should be made available locally and/or transferred onward as appropriate, possibly after further processing. If the server did not want the article, it should reject it with 441 instead of accepting it and silently discarding it.

That is a useful commitment, but it does not collapse the rest of Netnews. The specification warns that a client must not assume the article is available to readers without checking, for example with STAT. An injecting agent may need to forward an unapproved article to a moderator. A serving agent may not yet expose it. Relaying agents may see it at different times, and local retention remains local.

Thus two observations answer different questions. 240 says the posting transaction was affirmatively accepted for the server's next processing steps. A successful reading lookup says a particular serving view can now retrieve the article. A missing lookup cannot reverse the first answer, especially while moderation is pending.

The lost answer made visibility a dangerous test

RFC 3977 addresses the failure directly. If a session is interrupted before the client receives the final response, a positive response might already have been sent and lost. In a later session, the client should either check whether posting succeeded before resending or ensure that the server allocates the same Message-ID to the new attempt.

The specification prefers stable identity. Its reason is subtle: the article might not yet be readable. Moderation is the named example. A client that treats “not found” as proof of rejection can submit again while the first copy is merely waiting in another stage.

The protocol therefore refuses an attractive but false shortcut. Public absence is not reliable negative evidence about an earlier injection transaction. The system needs a reconciliation key that survives the gap.

One name made the retry recognizable

RFC 3977's appendix says that clients prepared to resend should, for email or Netnews articles, include a Message-ID header whose contents remain identical across attempts. Servers should recognize two POSTed articles bearing the same header contents as identical and allocate the same message identifier.

This is narrower than the entire history of Message-ID. RFC 5536 defines the field as a globally unique identifier and notes how heavily Netnews depends on uniqueness and fast comparison. RFC 5537 explains why: flood-fill propagation means the same article can arrive from several peers, so relaying and serving agents maintain a history of identifiers to suppress repeats.

For the lost-POST case, the identifier is not a transaction receipt. It does not prove that the first upload succeeded, authenticate the poster or certify byte-for-byte integrity. It simply prevents the client's uncertain second attempt from declaring itself a new article. The server and downstream history machinery can align both observations with one intended object.

That is why generating a fresh Message-ID for the retry would be an operational error even if every paragraph were unchanged. It would turn uncertainty about one post into two independent identities capable of separate propagation, moderation and retention.

Injection and reading belonged to different agents

RFC 5537 supplies the architectural map. A posting agent prepares a proto-article and passes it to an injecting agent. The injecting agent validates it, adds required fields when necessary, routes moderated material and hands conforming articles to relaying or serving agents. A serving agent makes articles available to readers.

Software often combines these roles in one server process, but the responsibilities remain distinct. That distinction protects the interpretation of evidence. A successful socket exchange with an injecting interface is not a measurement of global propagation. A STAT miss on one serving interface is not proof that no injecting decision occurred. A moderator's queue is neither failure nor public availability.

Normally, injection happens once. RFC 5537 warns that sending the same proto-article through multiple injection points risks duplication and loops; stable Message-ID, Date and Injection-Date fields help different paths recognize one article. The lost-reply retry is another place where preserving identity is safer than inventing a new submission.

The history file bounded harm rather than abolishing it

Duplicate suppression has limits. History entries cannot be retained forever without bound. A malformed or malicious identifier can collide. Different servers can apply different policies. A failure may occur before the injecting agent records the identifier, or after acceptance but before every later state is durable. Same-ID retry therefore does not amount to an exactly-once guarantee.

What it does is change the shape of the problem. Without stable identity, the operator faces two articles that merely look alike. With stable identity, the operator has two attempts that assert they concern one article and can be reconciled against the server's transaction, injection, moderation, relay and serving records.

The IANA NNTP Parameters registry lists POST as a standard capability and points to RFC 3977. That registration preserves an interoperable name; it does not say that a particular server accepts posts, retains a sufficient history or exposes an article now. Those are runtime facts.

The lasting design lesson is modest and powerful. A distributed protocol cannot always eliminate the interval in which work may have committed but acknowledgment is missing. It can preserve enough identity to stop the retry from becoming a different piece of work. NNTP kept the article's name stable, and in doing so kept an uncertain response from multiplying the article itself.

Sources