Summary
Approvednames the persons or entities authorizing a Netnews article for posting. It does not replace the article's author or prove that the named mailbox supplied the field.- If a proto-article names any moderated group and lacks
Approved, the injecting agent must send it to the leftmost moderator or reject it. The article is not partly published to its ordinary destinations first. - With several moderated groups, approval can pass through several moderators. The final moderator adds the field and assumes responsibility for all required approvals, while the injecting agent authenticates that moderator through a separate channel.
One article, three destinations, no partial publication
Imagine a proto-article addressed to an ordinary technical group and two moderated groups. Its author presses post. The ordinary group could accept direct submissions, but the other two cannot. The article contains no Approved field.
The injecting agent does not make one public copy for the ordinary group and put two other copies into review. Under the later Netnews architecture, it holds the proto-article intact and forwards it to the moderator of the leftmost moderated group—or rejects it if forwarding is impossible. Normal injection has not yet happened.
The first moderator may approve and pass the article to the second. When every moderated destination has agreed, the final moderator adds Approved, identifies the approving authority and sends the article back for injection. Only then does one article enter all three groups.
This is more than a queueing detail. It shows that authorship, editorial permission and network admission were separate acts performed by different roles.
A moderator's address entered the article early
RFC 1036 made the basic split visible in 1987. An article posted to a moderated newsgroup required an Approved line. The moderator was expected to add it and place a mail address in the field. The same field also appeared in certain control-message workflows.
The author's From line remained the author's. Approval did not rewrite the source of the prose. Instead, a second identity entered the header to state that a person responsible for a different decision had authorized publication.
That distinction matters because an author can be authentic without having the right to publish directly into a moderated forum. Conversely, a moderator can authorize an article without becoming its author. The field preserved both attributions rather than collapsing them into one sender.
The server advertised a normal path, not a personal entitlement
RFC 3977 gave clients a way to see how a server normally handled a group. In LIST ACTIVE, status y meant posting was permitted, n meant it was not permitted and m meant postings would be forwarded to the moderator.
The same specification warns that group status is not necessarily customized to the current client. A specially privileged client might do something different; a client forbidden to post would not gain rights merely because a group displayed y.
The m flag therefore described a route through an editorial authority, not a universal access-control token. It told a posting client what generally happened next. It did not name the moderator, certify the moderator's credentials or decide the article.
Approved was a list of approving identities
RFC 5536 defines the field precisely as a mailbox-list. Its addresses, and possibly full names, indicate the persons or entities approving the article for posting. Its principal uses are moderated articles and group control messages.
The grammar can carry several approvers. That makes it suitable for an article crossing more than one moderated jurisdiction, but the syntax still answers a limited question: whom does the article claim as its approving authority?
It does not answer whether the mailbox exists, whether the owner actually reviewed this article, whether the address is currently a moderator, or whether a receiving site trusts that authority. A well-formed mailbox list is structured attribution, not a cryptographic attestation.
The whole proto-article left the injection path
RFC 5537 places moderation inside the injection procedure. If Newsgroups contains one or more moderated groups and the proto-article lacks Approved, the injecting agent must forward it to a moderator or reject it. It performs that handoff after adding Message-ID and Date when necessary, but before adding normal injection trace fields.
The ordering keeps the object on the pre-publication side of the boundary. It has enough identity to survive the review journey, yet it has not been represented as injected news. The moderator may receive it as encapsulated application/news-transmission, as an email carrying news fields, or through another mechanism that preserves the proto-article without injecting it.
The injecting agent chooses the moderator of the leftmost moderated group. That rule supplies deterministic progress when a crosspost spans several independent approval domains. It does not imply that the leftmost moderator speaks for all the others.
Several moderators could pass responsibility forward
RFC 5537 allows moderators to coordinate directly or forward the proto-article through the remaining moderated groups. A moderator can record an intermediate indication of approval and send the item to the leftmost group that has not yet approved it.
The final step is deliberately weighty. Once no unapproved moderated destination remains, a moderator adds the Approved field, identifying that moderator and, insofar as possible, the other approvers. The moderator taking this step assumes responsibility for ensuring that every moderated group named in the article has approved it.
The field therefore records the conclusion of a workflow, not merely the opinion of the last person in a chain. Yet the visible list is still not the workflow itself. It cannot show what criteria were applied, how moderators coordinated, which edits they made or what evidence the final moderator examined.
Moderators may change headers or body under their own criteria, although minimal changes are recommended because modification can invalidate signatures created by the poster or earlier moderators. Again, authority to approve and authorship of the original text remain related but distinct.
A forged header could look perfectly valid
The security section of RFC 5537 states the weakness without euphemism: a malicious poster may add an Approved field to bypass moderation. Nothing in mailbox-list syntax prevents that act.
Injecting agents should therefore verify that an article approved for a moderated group is being injected by the moderator. The trust signal comes from authentication information in the underlying transport or another mechanism arranged with that moderator. The RFC notes that there was no standardized method for authenticating moderated-group approval, even though non-standard methods existed.
This divides the system into two layers. The article carries portable evidence about who is said to have approved. The injection relationship supplies local evidence that the article really arrived through an authorized moderator channel. Removing either layer causes a different failure: without the field, downstream agents lack the portable attribution; without external authentication, a poster can manufacture the attribution.
Registration stabilized the assertion, not the trust relationship
The IANA Message Headers Registry records Approved as a standard Netnews field linked to RFC 5536. Implementations can agree on its spelling, applicable protocol and normative definition.
The registry does not appoint moderators, publish current rosters, authenticate mailbox owners or force a server to honor a claimed approver. Nor do the official sources establish how current Usenet providers implement moderation. The standard field crosses systems; the trust relationship remains administered at their edges.
Editorial authority travelled without becoming authorship
Approved solved a narrow but difficult distributed problem. Once an article had passed moderation, relays needed a portable way to preserve that fact and attribute it without replacing the author. A mailbox list was sufficient to carry the assertion.
It was not sufficient to secure the assertion. Security lived in the injecting agent's knowledge of the moderator and in the authenticated channel through which the article returned. The field could open the publication path only because a local boundary had already decided whom to believe.
That architecture resists two common confusions. Approval is not authorship, and readable identity is not authenticated identity. Netnews placed both distinctions in one header's journey: the author wrote the article, the moderator authorized its destination, and the injecting agent decided whether the claimed authority was credible enough to admit it.
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
