Netnews Architecture and Protocols

The Hippocratic Principle — 'first, do no harm' — is identified as even more important than the Internet Robustness Principle for Netnews, because a locally suboptimal decision (such as silently accepting and re-transmitting a malformed article) can be catastrophically amplified by thousands of hosts within minutes.

The new Injection-Date header field (introduced in this revision) allows the Date header field to record article composition time even when injection is delayed. However, implementations predating this specification ignore Injection-Date and use Date for cutoff checks, so articles with a stale Date will still propagate poorly on legacy servers.

The message/news MIME type is declared obsolete by this document; it was never widely implemented and commonly fell back to application/octet-stream handling. Implementations SHOULD use message/rfc822 in its place when transmitting news articles via mail for human reading.

A serving agent MUST reject any article without an Approved header field that is posted to a newsgroup listed as moderated, and MUST reject any article that does not include all mandatory header fields or contains header fields with invalid contents.

Agents MUST either ignore or reject control messages with unrecognized types. The presence of a Subject header field beginning with 'cmsg ' MUST NOT cause an article to be treated as a control message; only the presence of a Control header field confers that status.

All news server components (injecting, relaying, and serving agents) MUST prepend their path-identity to the Path header field when processing an article. Injecting agents MUST also use the same identity in Injection-Info header fields they add.

An incoming gateway MUST add a Sender header field containing the mailbox of the gateway administrator. If the original message already contained a Sender header field, it SHOULD be renamed to Original-Sender to preserve its contents.

email

An incoming gateway MUST NOT gate the same message twice. It MUST pass the resulting proto-article to an injecting agent (not directly to a relaying agent), and MUST NOT pass control messages without removing or renaming the Control or Supersedes header fields.

An injecting agent MUST forward a proto-article for a moderated group to the moderator of the leftmost moderated newsgroup, customarily via email. The preferred encapsulation method uses Content-Type application/news-transmission with usage=moderate, but the direct email method is more widely deployed.

email

An injecting agent MUST NOT alter the body of an article in any way (including Content-Transfer-Encoding changes), MUST NOT alter or delete any existing Message-ID header field, and SHOULD NOT alter, delete, or reorder any existing header fields except Path.

An injecting agent MUST reject any proto-article that lacks required mandatory header fields, contains Injection-Info or Xref header fields, has a Path header field containing the 'POSTED' diag-keyword, or is syntactically invalid per RFC 5536.

An injecting agent SHOULD reject articles whose Injection-Date or Date header field is more than 24 hours in the future, and SHOULD reject articles dated too far in the past; the past-rejection interval SHOULD NOT be shorter than 72 hours.

Each agent accepting an article MUST prepend '!' followed by its primary path-identity to the Path header field. Injecting agents SHOULD prepend '!.POSTED'; relaying and serving agents SHOULD prepend a path-diagnostic (diag-match '!', 'MISMATCH', or 'SEEN') immediately before their identity.

If the Newsgroups header field contains a moderated group and the proto-article lacks an Approved header field, the injecting agent MUST either forward the proto-article to the moderator (per Section 3.5.1) or reject it. This forwarding is performed before adding Injection-Info and Injection-Date headers.

Relaying agents MUST NOT alter, delete, or rearrange any part of an article except for the Path and Xref header fields, and MUST NOT modify the body. If an article is not acceptable as-is, it MUST be rejected rather than modified.

Relaying and serving agents MUST keep a history of articles already seen and use it to reject duplicate offers. History records may be pruned using a cutoff interval (conventionally no less than seven days for Usenet) based on Injection-Date or Date.

Serving agents MUST NOT create new newsgroups simply because an unrecognized newsgroup name appears in the Newsgroups header field, and MUST remove any Xref header field from each received article (unless specially configured to preserve it).

The References header field of a followup MUST be constructed by appending the parent article's Message-ID to the parent's References content. If trimming is required to stay under 998 characters, the first message identifier and the last two MUST NOT be removed.

Transports for Netnews articles MUST treat articles as uninterpreted sequences of octets, excluding NUL (%d00, which MUST NOT occur), and CR (%d13) and LF (%d10) MUST only appear as a CR+LF pair denoting a line separator.

Transports MUST convey all header fields unmodified, including octets in the range 128–255. Transports for relaying and serving agents MUST, and transports for other agents SHOULD, convey lines even if they exceed 998 characters in length.

When multiple injection is intended, the posting agent MUST supply identical Message-ID, Date, and Injection-Date header fields in all copies of the proto-article. Re-injection of an already-injected article requires removing Xref and removing or renaming Injection-Info and Path header fields first.

A proto-article is the format used by a posting agent when offering an article to an injecting agent. It MUST NOT contain Injection-Info or Xref header fields, MUST NOT have 'POSTED' in the Path diagnostic, and MAY omit Message-ID, Date, and Path header fields.

The cancel control message (Control header value 'cancel <msg-id>') requests that the identified article be removed. The Supersedes header field in an ordinary article has a similar effect: relaying and serving agents SHOULD cancel the superseded article if they choose to honor it.

The newgroup control message (Control header value 'newgroup <newsgroup-name> [moderated]') requests creation of a new newsgroup. Its body SHOULD be of type application/news-groupinfo providing a description; a serving agent need not act on it and SHOULD authenticate the sender.

The Original-Sender header field preserves the Sender header field from a message received by an incoming gateway. Its ABNF is: Original-Sender-header = 'Original-Sender' ':' SP mailbox, where mailbox is as defined in RFC 5322.

email

RFC 5537 registers the application/news-checkgroups MIME media type with IANA. Its body lists all newsgroups within a hierarchy; the list is considered complete for any hierarchy represented, so all groups in that hierarchy MUST be listed unless scope is externally limited.

registry

RFC 5537 registers the application/news-groupinfo MIME media type with IANA. Its body contains a newsgroup name, description, and moderation status in a backward-compatible format; moderated groups MUST be marked by appending the case-sensitive text ' (Moderated)'.

registry

RFC 5537 registers the application/news-transmission MIME media type with IANA. It encapsulates a complete proto-article or relayed article for injection, relay, or moderation, with an optional usage parameter ('moderate', 'inject', or 'relay'). Article batches are not permitted.

registry

The Netnews flooding algorithm amplifies any forged or malicious article to thousands of servers within minutes. Agents (other than moderators) MUST NOT modify articles; unacceptable articles MUST be rejected rather than corrected, to prevent undetected corruption propagating network-wide.

security

The Path and Injection-Info header fields may expose internal network topology, IP addresses of dialup or internal hosts, and server configurations to all readers of an article. Injecting agents should carefully consider what trace information they disclose.

security, privacy

There is no standardized mechanism for authenticating the sender of a control message or verifying that its contents were sent by the claimed originator. Unstandardized mechanisms such as PGP-based signature verification (PGPVERIFY) exist but are not required by this specification.

security