Summary

  • Date records when the creator considered the message complete and ready for transport; it does not record actual network entry.
  • Injection-Date added a separate entry clock for bounded stale and duplicate-history decisions without rewriting the creator's date or each server's local arrival time.

The draft that arrived four days late

Imagine a writer finishing a Netnews article while away from a connection. The article receives its Date on Monday. It waits on the machine until Friday, when a posting agent can finally offer it to a news server.

To the writer, nothing is wrong. Monday is when the text was completed. To a relay maintaining a finite history of previously seen articles, the same value can look dangerous. Old traffic may be a duplicate returning after its Message-ID record has been discarded. A cutoff protects both storage and flood-fill capacity.

One timestamp now faces incompatible demands. Preserve Monday, and an older implementation may reject a newly entered article as stale. Replace Monday with Friday, and the record falsely moves the act of composition. The apparent choice is between reach and chronology.

Injection-Date resolved the conflict by refusing to replace the first date. It gave the entry boundary its own observation.

Date began as one durable line

The 1987 RFC 1036 called Date, formerly Posted, the date a message was originally posted to the network. It required the value to remain unchanged as the message propagated. That was a useful invariant: downstream systems could not silently rewrite the article's apparent beginning at every hop.

Internet message syntax later made the creator's role more exact. RFC 5322 says the origination date is when the creator indicated that the message was complete and ready to enter delivery. It explicitly distinguishes that event from actual transport. Its example is a portable computer that queues a message while offline; the date belongs to queuing, not to the later connection.

That definition protects historical meaning. It also exposes why the field is weak evidence for network admission. The value may be supplied before a long delay. It depends on the creator's clock. It can be mistaken or deliberately misleading. Even a perfectly honest value answers a different question from the one a relay needs to ask.

Duplicate suppression created a memory problem

Netnews spreads articles among independent relaying and serving agents. A server must not accept the same article over and over. RFC 5537 therefore requires those agents to keep a history of articles already seen and reject repeat offers.

Message-ID provides the durable comparison key, but remembering every identifier forever would make the history database grow without bound. The protocol permits a cutoff. An article dated farther in the past than the interval may be rejected; old history entries can then be dropped because any return would fail the date test. RFC 5537 describes at least seven days as conventional for Usenet and warns against a cutoff shorter than normal propagation time.

The economy is clear. The date does not prove duplication. It allows an operator to bound the evidence retained for detecting duplication. A short interval saves memory sooner but can discard unseen delayed traffic. A long interval protects propagation at a higher storage and lookup cost.

When the only available clock was composition time, that tradeoff inherited an unrelated delay. A careful writer preserving an old draft could look identical to an old article recirculating after its history record vanished.

A second clock with a narrower authority

RFC 5536 defines Injection-Date as the date and time an article was injected into the network. Its stated purpose is precise: stale checks can use a time added by a news server at injection rather than a time added by a user agent during composition.

The standard requires the field when an article is injected, while also requiring agents to accept articles without it for compatibility with earlier software. If the field is absent, RFC 5537 falls back to Date for the relevant checks. The migration preserved interoperability but did not pretend every peer learned the new distinction at once.

Most importantly, adding the field does not authorize changing the first one. RFC 5536 says agents must not alter a pre-existing Date when they add Injection-Date. It also warns that unsynchronised clocks can make the injection value appear earlier than the composition value. Order on the page is not proof that the clocks agree.

The new field replaced the used but undocumented NNTP-Posting-Date, which the standard deprecated. Registration turned an operational habit into shared syntax and bounded semantics. It did not create a global time service.

Entry time changed the history calculation

RFC 5537 defines the article date used by the common history optimization as Injection-Date when present and Date otherwise. Relaying and serving agents examine that value for excessive future time and, when using the cutoff strategy, reject values outside the retained interval.

An alternative strategy ages a history entry from when that particular agent first saw the article. Under the RFC's described rule, retention then extends at least 24 hours beyond the cutoff to accommodate permitted future-date error. This introduces a third operational perspective: the article's declared composition, its first network injection, and its arrival at this server.

RFC 3977 makes the local perspective explicit. NNTP servers maintain an arrival timestamp and issue article numbers in its order. That timestamp belongs to one server. It does not replace the shared injection time, just as injection does not replace composition.

Three clocks are not redundant. Date records when the creator declared the article ready. Injection-Date records entry into the Netnews system under the injection rules. Arrival time records when one server received the article and supports its local ordering. Each marks a different custody boundary.

Collapsing them would make a local delay look like author behaviour, or an author's delay look like network recirculation.

Multiple entry points still needed one history

Netnews also permitted the same article to be offered at more than one injection point for resilience or disconnected networks. The intent was not to mint separate articles. Ordinary Message-ID duplicate suppression should make converging paths resolve to one accepted article.

For that reason, RFC 5537 requires copies of a multiply injected proto-article to carry identical Message-ID, Date and Injection-Date values. When an existing article is converted back for injection elsewhere, those three fields are retained unmodified. Preserving the second clock prevents each entry point from making the same article look newly born.

This rule reveals the field's scope. Injection-Date is not simply whatever current time a later gateway prefers. Under multiple injection, it becomes part of the stable evidence that lets several entry paths converge without resetting age.

Compatibility kept the old ambiguity alive

The new distinction could not abolish older practice. RFC 5537 notes that pre-standard implementations ignore Injection-Date and continue to use Date for stale rejection. A substantially old composition date may therefore propagate poorly even when a correct injection field is present.

Posting agents are told to add Injection-Date before submission in certain cases when Message-ID and Date already exist. They should do so when composition is more than a day old and must do so for multiple injection. Injecting agents perform future and past checks and add the current field when the protocol conditions require it.

These duties reduce ambiguity at the point most able to explain a rejection to the poster. They do not force every downstream implementation to understand the result. Backward compatibility preserves communication by carrying both old and new evidence; it also preserves a period in which peers can reach different decisions from the same article.

The second date was not a certificate

An injection timestamp is an assertion by an agent operating at an entry boundary. It is not a cryptographic signature, a proof of authorship or a guarantee that the clock was correct. RFC 5536 explicitly anticipates clock disagreement. The field also does not show when every server received the article, when a moderator approved it, when a reader saw it or when local retention will remove it.

The current IANA Message Headers Registry lists Injection-Date as a standard Netnews field with RFC 5536 as its reference. Registration gives implementations a stable name. It does not attest to the truth of an individual value or prove universal deployment.

The historical achievement was narrower and more durable. Netnews learned that honest chronology and operational admission need not compete for one field. The creator kept the first date. The network added a second. Every later server still retained its own arrival evidence. Reliability came from limiting each clock to the decision it could actually support.