RFC 5537 Proposed Standard Message format

Netnews Architecture and Protocols

This document defines the architecture of Netnews systems and specifies the correct manipulation and interpretation of Netnews articles by software that originates, distributes, stores, and displays them. It also specifies the requirements that must be met by any protocol used to transport and serve Netnews articles. [STANDARDS-TRACK]

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
November 2009
Authors
R. Allbery, C. Lindsey
Read it
rfc-editor.org · errata · DOI

Replaces RFC 850: Standard for interchange of USENET messages, RFC 1036: Standard for interchange of USENET messages, RFC 1849: "Son of 1036": News Article Format and Transmission.

This document is current and has been amended. 1 later RFC has changed part of it. Nothing on the RFC itself tells you this.

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 92 must, 84 should, 35 may.

2 Transport

  • MUSTTransports for Netnews articles MUST treat news articles as uninterpreted sequences of octets, excluding the values %d00 (which may not occur in Netnews articles), %d13, and %d10 (which MUST only appear in Netnews articles as a pair in that order and which, together, denote a line separator).
  • MUSTIn particular, transports MUST convey all header fields unmodified (including header fields within message/rfc822 objects in article bodies), even if they contain octets in the range of 128 to 255.
  • MUSTFurthermore, transports for relaying and serving agents MUST, and transports for other agents SHOULD, convey lines even if they exceed 998 characters in length, especially in article bodies.

3 Duties of Agents

  • MUSTThe requirements of all three agents MUST still be met when the news server is performing the functions of those agents.

3.1 General Principles

  • SHOULDAs applied to Netnews, this primarily means that unwanted or non- compliant articles SHOULD be rejected as early as possible, but once they are in general circulation, relaying and serving agents may wish to accept them where possible rather than lose information.
  • SHOULDPosting agents and injecting agents SHOULD therefore be maximally strict in their application of both this protocol and [RFC5536], and reading agents SHOULD be robust in the presence of violations of the Netnews article format where possible.
  • MAYThis document specifies how articles are to be treated if they are accepted and specifies some cases where they must be rejected, but an agent MAY always reject any article for other reasons than those stated here.
  • MUST NOTAccordingly, agents (other than moderators) MUST NOT modify articles in ways other than described here.
  • MUSTUnacceptable articles MUST be rejected rather than corrected.

3.2 The Path Header Field

  • MUSTAll news server components (injecting agents, relaying agents, and serving agents) MUST identify themselves, when processing an article, by prepending their <path-identity> (defined in Section 3.1.5 of [RFC5536]) to the Path header field.
  • MUSTInjecting agents MUST also use the same identity in Injection-Info header fields that they add, and serving and relaying agents SHOULD use the same identity in any Xref header fields they add.
  • SHOULD NOTThis option SHOULD NOT be used unless the earlier options are unavailable or unless the name is of longstanding usage.
  • SHOULDThe <path-identity> therefore SHOULD be all lowercase and implementations SHOULD compare identities case-insensitively.

3.2.1 Constructing the Path Header Field

  • MAYIf a relaying or serving agent receives an article from an injecting or serving agent that is part of the same news server, it MAY leave the Path header field of the article unchanged.
  • MUSTOtherwise, every injecting, relaying, or serving agent that accepts an article MUST update the Path header field as follows.
  • MUSTThe agent MUST prepend "!" to the Path header field content.
  • SHOULDAn injecting agent SHOULD prepend the <path-diagnostic> "!.POSTED", optionally followed by "." and the FQDN or IP address of the source, to the Path header field content.
  • SHOULDA relaying or serving agent SHOULD prepend a <path-diagnostic> to the Path header field content, where the <path-diagnostic> is chosen as follows:
  • MAYThe agent MAY then prepend to the Path header field content "!" or "!!" followed by an additional <path-identity> for itself other than its primary one.
  • RECOMMENDEDUsing "!!", and thereby adding a <diag-match> since the <path-identity> clearly is verified, is RECOMMENDED.
  • MUSTEach of these <path-identity>s MUST meet the requirements set out in Section 3.2.
  • MUSTFinally, the agent MUST prepend its primary <path-identity> to the Path header field content.
  • MAYAny agent that modifies the Path header field MAY fold it by inserting FWS (folding white space) immediately after any <path- identity> or <diag-other> it added (see Section 3.1.5 of [RFC5536] for allowable locations for FWS).

3.3 Article History and Duplicate Suppression

  • MUSTRelaying and serving agents therefore MUST keep a record of articles they have already seen and use that record to reject additional offers of the same article.
  • MAYo Agents MAY select a cutoff interval and reject any article with a date farther in the past than that cutoff interval.
  • MAYo Agents that enforce such a cutoff MAY then drop records of articles that had dates older than the cutoff from their history databases.
  • MAYo Alternatively, agents MAY drop history records according to the date when the article was first seen by that agent rather than the date of the article.
  • MUSTIn this case, the history retention interval MUST be at least 24 hours longer than the cutoff interval to allow for articles dated in the future.

3.4 Duties of a Posting Agent

  • SHOULDPosting agents SHOULD ensure that proto-articles they create are valid according to [RFC5536] and any other applicable policies.
  • MUST NOTThey MUST NOT create any Injection-Info header field; this header field may only be added by the injecting agent.
  • MAYIf the proto-article already contains both Message-ID and Date header fields, posting agents MAY add an Injection-Date header field to that proto-article immediately before passing that proto-article to an injection agent.
  • SHOULDThey SHOULD do so if the Date header field (representing the composition time of the proto-article) is more than a day in the past at the time of injection.
  • MUSTThey MUST do so if the proto-article is being submitted to more than one injecting agent; see Section 3.4.2.
  • MAYContrary to [RFC5322], which implies that the mailbox or mailboxes in the From header field should be that of the poster or posters, a poster who does not, for whatever reason, wish to use his own mailbox MAY use any mailbox ending in the top-level domain ".invalid" [RFC2606].
  • SHOULDPosting agents meant for use by ordinary posters SHOULD reject any attempt to post an article that cancels or supersedes (via the Supersedes header field) another article of which the poster is not the author or sender.

3.4.1 Proto-Articles

  • SHOULD NOTA proto-article is only for transmission to an injecting agent and SHOULD NOT be transmitted to any other agent.
  • MUST NOTA proto-article has the same format as a normal article except that the Injection-Info and Xref header fields MUST NOT be present, the Path header field SHOULD NOT contain a "POSTED" <diag-keyword>, and any of the following mandatory header fields MAY be omitted: Message-ID, Date, and Path.
  • MUSTIn all other respects, a proto-article MUST be a valid Netnews article.
  • MUST NOTIn particular, the header fields that may be omitted MUST NOT be present with invalid content.
  • MUSTIf a posting agent intends to offer the same proto-article to multiple injecting agents, the header fields Message-ID, Date, and Injection-Date MUST be present and identical in all copies of the proto-article.

3.4.2 Multiple Injection of Articles

  • SHOULDWhenever possible, multiple injection SHOULD be done by offering the same proto-article to multiple injecting agents.
  • MUSTThe posting agent MUST supply the Message-ID, Date, and Injection-Date header fields, and the proto-article as offered to each injecting agent MUST be identical.
  • MUSTIn this case, the posting agent MUST remove any Xref header field and rename or remove any Injection-Info, Path, and other trace header fields before passing it to another injecting agent.
  • MUST(This converts the article back into a proto-article.) It MUST retain unmodified the Message-ID, Date, and Injection-Date header fields.
  • MUST NOTIt MUST NOT add an Injection-Date header field if it is missing from the existing article.
  • SHOULDMultiple injection of an article that lists one or more moderated newsgroups in its Newsgroups header field SHOULD only be done by a moderator and MUST only be done after the proto-article has been approved for all moderated groups to which it is to be posted and after an Approved header field has been added (see Section 3.9).

3.4.3 Followups

  • MAYHowever, posters MAY then override that default before posting.
  • SHOULD NOTDespite the historic practice of some posting agents, the Keywords header field SHOULD NOT be inherited by default from the precursor article.
  • MUST NOTIf the Followup-To header field of the precursor article consists of "poster", the followup MUST NOT be posted by default but, by default, is to be emailed to the address given in the precursor's Reply-To or From header field following the rules for an email reply [RFC5322].
  • MAYThis action MAY be overridden by the poster, in which case the posting agent should continue as if the Followup-To header field in the precursor did not exist.
  • SHOULDThe Newsgroups header field SHOULD, by default, be inherited from the precursor's Followup-To header field if present; otherwise, it is inherited from the precursor's Newsgroups header field.
  • SHOULDThe Subject header field SHOULD, by default, be inherited from that of the precursor.
  • MAYThe case-sensitive string "Re: " (including the space after the colon) MAY be prepended to the content of its Subject header field unless it already begins with that string.
  • SHOULDThe Distribution header field SHOULD, by default, be inherited from the precursor's Distribution header field, if present.
  • MUSTThe followup MUST have a References header field referring to its precursor, constructed in accordance with Section 3.4.4.

3.4.4 Construction of the References Header Field

  • MUSTThe content of the new article's References header field MUST be formed from the content of the parent's References header field if present, followed by the content of the Message-ID header field of the parent.
  • MUSTIf the parent had a References header, FWS as defined in [RFC5536] MUST be added between its content and the Message-ID header field content.
  • MUSTIf the resulting References header field would, after unfolding, exceed 998 characters in length (including its field name but not the final CRLF), it MUST be trimmed (and otherwise MAY be trimmed).
  • MUST NOTTrimming means removing any number of message identifiers from its content, except that the first message identifier and the last two MUST NOT be removed.
  • REQUIREDAn essential property of the References header field, guaranteed by the above procedure and REQUIRED to be maintained by any extensions to this protocol, is that an article MUST NOT precede one of its parents.

3.5 Duties of an Injecting Agent

  • MUSTAn injecting agent MUST have available a list (possibly empty) of moderated groups for which it accepts articles and the corresponding submission addresses.
  • SHOULDIt SHOULD have available a list of valid newsgroups to catch articles not posted to a valid newsgroup and therefore likely to be silently discarded by relaying and serving agents.
  • SHOULDIt SHOULD verify that the article is from a trusted source (for example, by relying on the authorization capability of the underlying transport used to talk to the posting agent).
  • MUSTIt MUST reject any proto-article that does not have the proper mandatory header fields for a proto-article, that has Injection- Info or Xref header fields, that has a Path header field containing the "POSTED" <diag-keyword>, or that is not syntactically valid as defined by [RFC5536].
  • SHOULDIt SHOULD reject any proto-article that contains a header field deprecated for Netnews (see, for example, [RFC3798]).
  • MAYIt MAY reject any proto- article that contains trace header fields (e.g., NNTP-Posting- Host) indicating that it was already injected by an injecting agent that did not add Injection-Info or Injection-Date.
  • SHOULDIt SHOULD reject any article whose Injection-Date or Date header field is more than 24 hours into the future (and MAY use a margin less than 24 hours).
  • SHOULDIt SHOULD reject any article whose Injection-Date header field is too far in the past (older than the cutoff interval of a relaying agent that the injecting agent is using, for example).
  • SHOULDIt SHOULD similarly reject any article whose Date header field is too far in the past, since not all news servers support Injection-Date and only the injecting agent
  • SHOULD NOTIn either case, this interval SHOULD NOT be any shorter than 72 hours into the past.
  • SHOULDIt SHOULD reject any proto-article whose Newsgroups header field does not contain at least one <newsgroup-name> for a valid group, or that contains a <newsgroup-name> reserved for specific purposes by Section 3.1.4 of [RFC5536] unless that specific purpose or local agreement applies to the proto-article being processed.
  • MUSTThe Message-ID and Date header fields with appropriate contents MUST be added when not present in the proto-article.
  • MUST NOTThe injecting agent MUST NOT alter the body of the article in any way (including any change of Content-Transfer-Encoding).
  • MAYIt MAY add other header fields not already provided by the poster, but injecting agents are encouraged to use the Injection-Info header for such information and to minimize the addition of other headers.
  • SHOULD NOTIt SHOULD NOT alter, delete, or reorder any existing header field except the Path header field.
  • MUST NOTIt MUST NOT alter or delete any existing Message-ID header field.
  • MUSTIf the Newsgroups header contains one or more moderated groups and the proto-article does not contain an Approved header field, the injecting agent MUST either forward it to a moderator as specified in Section 3.5.1 or, if that is not possible, reject it.
  • MUSTThis forwarding MUST be done after adding the Message-ID and Date headers if required, and before adding the Injection- Info and Injection-Date headers.
  • MUSTOtherwise, a Path header field with a <tail-entry> MUST be added if not already present.
  • MUSTThe injecting agent MUST then update the Path header field as described in Section 3.2.1.
  • SHOULDAn Injection-Info header field SHOULD be added that identifies the source of the article and possibly other trace information as described in Section 3.2.8 of [RFC5536].
  • MUST NOTIf the proto-article already had an Injection-Date header field, it MUST NOT be modified or replaced.
  • MUST NOTIf the proto-article had both a Message-ID header field and a Date header field, an Injection-Date header field MUST NOT be added, since the proto- article may have been multiply injected by a posting agent that
  • MUSTOtherwise, the injecting agent MUST add an Injection-Date header field containing the current date and time.

3.5.1 Forwarding Messages to a Moderator

  • MUSTAn injecting agent MUST forward the proto-article to the moderator of the leftmost moderated group listed in the Newsgroups header field, customarily via email.
  • SHOULDThis SHOULD be done by creating an email message with a Content-Type of application/news-transmission with the usage parameter set to "moderate".
  • SHOULD NOTThe body SHOULD NOT contain any content other than the message.
  • SHOULDThe existing Message-ID header field SHOULD be retained.
  • SHOULD NOTAccordingly, the first method SHOULD NOT be used unless the moderator to which it is being forwarded is known to be able to handle this method.
  • MAYForwarding proto-articles to moderators via email is the most general method and the most common in large Netnews networks such as Usenet, but any means of forwarding the article that preserves it without injecting it MAY be used.

3.6 Duties of a Relaying Agent

  • SHOULDTo avoid bypass of injecting agent policies and forgery of Path and Injection-Info headers, relaying agents SHOULD accept articles only from trusted agents.
  • SHOULD NOTAn article SHOULD NOT be relayed unless the sending agent has been configured to supply, and the receiving agent to receive, at least one of the <newsgroup-name>s in its Newsgroups header field and at least one of the <dist-name>s in its Distribution header field (if present).
  • SHOULDExceptionally, control messages creating or removing newsgroups (newgroup or rmgroup control messages, for example) SHOULD be relayed if the affected group appears in its Newsgroups header field and both the sending and receiving relaying agents are configured to relay a newsgroup of that name (whether or not such a newsgroup exists).
  • SHOULD NOTIn order to avoid unnecessary relaying attempts, an article SHOULD NOT be relayed if the <path-identity> of the receiving agent (or some known alias thereof) appears as a <path-identity> (excluding within the <tail-entry> or following a "POSTED" <diag-keyword>) in its Path header field.
  • MUSTIt MUST reject any article without a Newsgroups header field or Message-ID header field, or without either an Injection-Date or Date header field.
  • MUSTIt MUST examine the Injection-Date header field or, if absent, the Date header field, and reject the article if that date is more than 24 hours into the future.
  • MAYIt MAY reject articles with dates in the future with a smaller margin than 24 hours.
  • MUSTIt MUST reject any article that has already been accepted.
  • MUSTIf it implements one of the mechanisms described in Section 3.3, this means that it MUST reject any article whose date falls outside the cutoff interval since it won't know whether or not such articles had been accepted previously.
  • SHOULDIt SHOULD reject any article that does not include all the mandatory header fields.
  • MAYIt MAY reject any article that contains header fields that do not have valid contents.
  • SHOULDIt SHOULD reject any article that matches an already-received cancel control message or the contents of the Supersedes header field of an accepted article, provided that the relaying agent has chosen (on the basis of local site policy) to honor that cancel control message or Supersedes header field.
  • MAYIt MAY reject any article without an Approved header field posted to a newsgroup known to be moderated.
  • MUSTIt MUST update the Path header field as described in Section 3.2.1.
  • MAYIt MAY delete any Xref header field already present.
  • MAYIt MAY add a new Xref header field for its own use (but recall that [RFC5536] permits at most one such header field).
  • SHOULDRelaying agents SHOULD, where possible in the underlying transport, inform the agent that passed the article to the relaying agent if the article was rejected.
  • MUST NOTRelaying agents MUST NOT inform any other external entity of the rejection of an article unless that external entity has explicitly requested that it be informed of such errors.
  • MUST NOTRelaying agents MUST NOT alter, delete, or rearrange any part of an article except for the Path and Xref header fields.
  • MUST NOTThey MUST NOT modify the body of articles in any way.
  • MUSTIf an article is not acceptable as is, the article MUST be rejected rather than modified.

3.7 Duties of a Serving Agent

  • SHOULD NOTIf the serving agent stores articles by newsgroup, control messages SHOULD NOT be stored in the newsgroups listed in the control message's Newsgroups header field.
  • SHOULDInstead, they SHOULD be stored in a newsgroup in the hierarchy "control", which is reserved for this purpose.
  • MUSTA serving agent MUST have available a list (possibly empty) of moderated groups for which it accepts articles so that it can reject unapproved articles posted to moderated groups.
  • MUSTIt MUST reject any article that does not include all the mandatory header fields or any article that contains header fields that do not have valid contents.
  • SHOULDIt SHOULD reject any article that matches an already-received and honored cancel message or Supersedes header field, following the same rules as a relaying agent (Section 3.6).
  • MUSTIt MUST reject any article without an Approved header field posted to any newsgroup listed as moderated.
  • MUSTIt MUST remove any Xref header field from each article (except when specially configured to preserve the <article-locator>s set by the sending site).
  • MAYIt then MAY (and usually will) add a new Xref header field (but recall that [RFC5536] permits at most one such header field).
  • MUST NOTServing agents MUST NOT create new newsgroups simply because an unrecognized <newsgroup-name> occurs in a Newsgroups header field.
  • MUST NOTServing agents MUST NOT alter, delete, or rearrange any part of an article except for the Path and Xref header fields.
  • MUST NOTThey MUST NOT modify the body of the articles in any way.

3.9 Duties of a Moderator

  • SHOULDModerators who may receive articles via email SHOULD be prepared to accept articles in either format.
  • SHOULDThis forwarding SHOULD be done following the procedure in Section 3.5.1.
  • MAYIt MAY be done by rotating the <newsgroup-name>s in the Newsgroups header field so that the leftmost unapproved newsgroup is the leftmost moderated newsgroup in that field and then posting it, letting the injecting agent do the forwarding.
  • MUSTHowever, when using this mechanism, they MUST first ensure that the article contains no Approved header field.
  • MAYModerators are also encouraged to retain the Date header field unless it appears to be stale (72 hours or more in the past) for reasons understood by the moderator (such as delays in the moderation process), in which case they MAY substitute the current date.
  • MUSTAny Injection-Date, Injection-Info, or Xref header fields already present MUST be removed.
  • MUSTAny Path header field MUST either be removed or truncated to only those entries following its "POSTED" <diag-keyword>, if any.

3.10 Duties of a Gateway

  • MUSTTo prevent this, a gateway MUST take precautions against loops, as detailed below.
  • SHOULDThe transformations applied to the message SHOULD be as minimal as possible while still accomplishing the gatewaying.
  • SHOULDIf bidirectional gatewaying (both an incoming and an outgoing gateway) is being set up between Netnews and some other medium, the incoming and outgoing gateways SHOULD be coordinated to avoid unintended reinjection of gated articles.
  • SHOULD NOTCircular gatewaying (gatewaying a message into another medium and then back into Netnews) SHOULD NOT be done; encapsulation of the article SHOULD be used instead where this is necessary.
  • SHOULDNewsgroups intended to be bidirectionally gated to a mailing list SHOULD therefore be moderated where possible, even if the moderator

3.10.2 Duties of an Incoming Gateway

  • MUST NOTAn incoming gateway MUST NOT gate the same message twice.
  • MUST NOTIt may not be possible to ensure this in the face of mangling or modification of the message, but at the very least a gateway, when given a copy of a message that it has already gated and that is identical except for trace header fields (like Received in Email or Path in Netnews), MUST NOT gate the message again.
  • SHOULDAn incoming gateway SHOULD take precautions against having this rule bypassed by modifications of the message that can be anticipated.
  • MUSTNews articles prepared by gateways MUST be valid news proto-articles (see Section 3.4.1).
  • MUSTThe gateway MUST then pass the article to an injecting agent, not directly to a relaying agent.
  • MUST NOTIncoming gateways MUST NOT pass control messages (articles containing a Control or Supersedes header field) without removing or renaming that header field.
  • MAYGateways MAY, however, generate cancel control messages for messages they have gatewayed.
  • SHOULDIf a gateway receives a message that it can determine is a valid equivalent of a cancel control message in the medium it is gatewaying, it SHOULD discard that message without gatewaying it, generate a corresponding cancel control message of its own, and inject that cancel control message.
  • SHOULDIf there is a message identifier that fills a role similar to that of the Message-ID header field in news, it SHOULD be used in the formation of the message identifier of the news article, perhaps with transformations required to meet the uniqueness requirement of Netnews and with the removal of any comments so as to comply with the syntax in Section 3.1.3 of [RFC5536].
  • SHOULDSuch transformations SHOULD be designed so that two messages with the same identifier generate the same Message-ID header field.
  • SHOULDExceptionally, if there are multiple incoming gateways for a particular set of messages, each to a different newsgroup(s), each one SHOULD generate a message identifier unique to that gateway.
  • MUSTEach incoming gateway nonetheless MUST ensure that it does not gate the same message twice.
  • MAYIf no date information is available, the gateway MAY supply a Date header field with the gateway's current date.
  • SHOULDIf only partial information is available (such as date but not time), this SHOULD be fleshed out to a full Date by adding default values rather than by discarding this information.
  • MUSTAn incoming gateway MUST add a Sender header field to the news article it forms by containing the <mailbox> of the administrator of the gateway.
  • SHOULDThe <display-name> portion of this <mailbox> SHOULD indicate that the entity responsible for injection of the message is a gateway.
  • SHOULDIf the original message already had a Sender header field, it SHOULD be renamed to Original-Sender so that its contents can be preserved.

4 Media Types

  • SHOULDThe media type message/rfc822 (defined in Section 5.2.1 of [RFC2046]) SHOULD be used in its place.
  • MAYEncoding considerations: A transfer-encoding different from that of the article transmitted MAY be supplied to ensure correct transmission over some 7bit transport medium.
  • MAYThe entity receiving the article may only implement one type of agent, in which case the parameter MAY be omitted.
  • MUSTOptional parameters: charset, which MUST be a charset registered for use with MIME text types.
  • MUSTEncoding considerations: 7bit or 8bit encoding MUST be used to maintain compatibility.
  • SHOULDAlthough optional, the <newsgroups-tag> SHOULD be included for backward compatibility.
  • MUST NOTThe <newsgroup-description> MUST NOT contain any occurrence of the string "(Moderated)" within it.
  • MUSTModerated newsgroups MUST be marked by appending the case-sensitive text " (Moderated)" at the end.
  • RECOMMENDEDUsing a charset of US- ASCII where possible is therefore RECOMMENDED; if not possible, UTF-8 [RFC3629] SHOULD be used.
  • MUSTRegardless of the charset used, the constraints of the above grammar MUST be met and the <newsgroup-name> MUST be represented in that charset using the same octets as would be used with a charset of US-ASCII.
  • MUST NOTThis media type therefore MUST NOT be used for conveying partial information about a hierarchy; if a group from a given hierarchy is present, all groups
  • MUSTthat exist in that hierarchy MUST be listed unless its scope is limited by external information, in which case all groups SHOULD be listed.
  • MUSTIn an actual message, the newsgroup name and description MUST be separated by one or more tabs (HTAB, ASCII %d09), not spaces.

5 Control Messages

  • MAYAgents MAY accept other control message types than those specified below, and MUST either ignore or reject control messages with unrecognized types.
  • MUST NOTContrary to [RFC1036], the presence of a Subject header field starting with the string "cmsg " MUST NOT cause an article to be interpreted as a control message.
  • MAYAgents MAY reject an article that has such a Subject header field and no Control header field as ambiguous.
  • MUST NOTLikewise, the presence of a <newsgroup-name> ending in ".ctl" in the Newsgroups header field or the presence of an Also- Control header field MUST NOT cause the article to be interpreted as a control message.

5.1 Authentication and Authorization

  • SHOULDAgents acting on control messages SHOULD take steps to authenticate control messages before acting on them, as determined by local authorization policy.
  • MAYThe following descriptions specify the actions that a control message requests, but an agent MAY always decline to act on any given control message.

5.2 Group Control Messages

  • MUSTBefore honoring any group control message, an agent MUST check the newsgroup or newsgroups affected by that control message and decline to create any newsgroups not in conformance with the restrictions in Section 3.1.4 of [RFC5536].
  • MUSTAll of the group control messages MUST have an Approved header field (Section 3.2.1 of [RFC5536]).
  • SHOULD NOTGroup control messages without an Approved header field SHOULD NOT be honored.
  • SHOULDGroup control messages affecting specific groups (newgroup and rmgroup control messages, for example) SHOULD include the <newsgroup- name> for the group or groups affected in their Newsgroups header field.
  • MAYOther newsgroups MAY be included in the Newsgroups header field so that the control message will reach more news servers, but due to the special relaying rules for group control messages (see Section 3.6) this is normally unnecessary and may be excessive.

5.2.1 The newgroup Control Message

  • SHOULDIf the request is honored, the moderation status of the group SHOULD be set in accordance with the presence or absence of the <newgroup- flag> "moderated".
  • MAYOther flags MAY be defined by extensions to this protocol and accepted by agents.
  • SHOULDIf an agent does not recognize the <newgroup-flag> of a newgroup control message, it SHOULD ignore that control message.
  • SHOULDThe body of a newgroup message SHOULD contain an entity of type application/news-groupinfo specifying the description of the newsgroup, either as the entire body or as an entity within a multipart/mixed object [RFC2046].
  • MUSTIf such an entity is present, the moderation status specified therein MUST match the moderation status specified by the <newgroup-flag>.
  • MAYThe body of a newgroup message MAY contain other entities (encapsulated in multipart/mixed) that provide additional information about the newsgroup or the circumstances of the control message.
  • MAYIn the absence of an application/news-groupinfo entity, a news server MAY search the body of the message for the line "For your newsgroups file:" and take the following line as a <newsgroups-line>.
  • SHOULDIf the request is honored and contains a newsgroup description, and if the news server honoring it stores newsgroup descriptions, the stored newsgroup description SHOULD be updated to the description specified in the control message, even if no other property of the group has changed.

5.2.2 The rmgroup Control Message

  • MAYThe body of the control message MAY contain anything, usually an explanatory text.

5.2.3 The checkgroups Control Message

  • MUST NOTSince much existing software does not honor the <chkscope> argument, the body of the checkgroups control message MUST NOT contain group statements for newsgroups outside the intended scope and SHOULD contain a correct newsgroup list even for sub-hierarchies excluded with "!" <chkscope> terms.
  • MUSTNews servers, however, MUST honor <chkscope> as specified here.
  • MUSTIf present, it MUST increase with every change to the newsgroup list, MUST NOT ever decrease, and MUST be included in all subsequent checkgroups control messages with the same scope.
  • SHOULDIf provided, news servers SHOULD remember the <chksernr> value of the previous checkgroups control message honored for a particular hierarchy or sub-hierarchy and decline to honor any subsequent checkgroups control message for the same hierarchy or sub-hierarchy with a smaller <chksernr> value or with no <chksernr> value.
  • SHOULDIt SHOULD be declared as such with appropriate MIME headers, but news servers SHOULD interpret checkgroups messages that lack the appropriate MIME headers as if the body were of type application/news-checkgroups for backward compatibility.

5.3 The cancel Control Message

  • SHOULDA serving agent that elects to honor a cancel message SHOULD make the article unavailable to reading agents (perhaps by deleting it completely).
  • SHOULDIf the cancel control message arrives before the article it targets, news servers choosing to honor it SHOULD remember the message identifier that was cancelled and reject the cancelled article when it arrives.
  • SHOULDTo best ensure that it will be relayed to the same news servers as the original message, a cancel control message SHOULD have the same Newsgroups header field as the message it is cancelling.
  • MUSTCancel control messages listing moderated newsgroups in their Newsgroups header field MUST contain an Approved header field like any other article in a moderated newsgroup.

5.4 The Supersedes Header Field

  • SHOULDAccordingly, news servers SHOULD apply to a Supersedes header field the same authentication and authorization checks as they would apply to cancel control messages.
  • SHOULDIf the Supersedes header field is honored, the news server SHOULD take the same actions as it would take when honoring a cancel control message for the given target article.
  • SHOULDThe article containing the Supersedes header field, whether or not the Supersedes header field is honored, SHOULD be handled as a normal article and SHOULD NOT receive the special treatment of control messages described in Section 3.7.

5.5 The ihave and sendme Control Messages

  • SHOULDThe message identifiers SHOULD be put in the body of the article, not in the Control header field, but news servers MAY recognize and process message identifiers in the Control header field for backward compatibility.
  • MUST NOTMessage identifiers MUST NOT be put in the Control header field if they are present in the body of the control message.
  • MUSTContrary to [RFC1036], the relayer-name MUST be given as the last argument in the Control header field.
  • SHOULD NOTArticles with such a group in their Newsgroups header fields SHOULD NOT be sent to any news server other than the one identified by <relayer-name>.

5.6 Obsolete Control Messages

  • SHOULD NOTThe following control message types are declared obsolete by this document and SHOULD NOT be sent or honored:

6.1 Compromise of System Integrity

  • SHOULDAdministrators of news servers SHOULD therefore take steps to verify the authenticity of control messages as discussed in Section 5.1.
  • SHOULDArticles containing Supersedes header fields are effectively cancel control messages and SHOULD be subject to the same checks as
  • SHOULDAll article contents, and particularly control message contents, SHOULD be handled with care and rigorously verified before any action is taken on the basis of the contents of the article.
  • SHOULDInjecting agents SHOULD verify that messages approved for a moderated newsgroup are being injected by the moderator using authentication information from the underlying transport or some other authentication mechanism arranged with the moderator.
  • SHOULDNews servers SHOULD use the facilities of the underlying transport to authenticate their peers and reject articles from injecting and relaying agents that do not follow the requirements of this protocol or the Netnews network.

6.2 Denial of Service

  • SHOULDAdministrators SHOULD therefore obtain a genuine copy of the article from their own serving agent before taking action in response to such a complaint.

8.2 Informative References

  • RECOMMENDEDo A new, backward-compatible Path header field format that permits standardized embedding of additional trace and authentication information is now RECOMMENDED.
  • REQUIREDo Trimming of the References header field is REQUIRED, and a mechanism for doing so is defined.
  • MUSTo Addition of the new Injection-Date header field is required in some circumstances for posting agents (Section 3.4.2) and injecting agents (Section 3.5), and MUST be used by news servers for date checks (Section 3.6).
  • SHOULDo A new media type is defined for transmitting Netnews articles through other media (Section 4.1), and moderators SHOULD prepare to receive submissions in that format (Section 3.5.1).

Every current email RFC