Netnews Article Format
This document specifies the syntax of Netnews articles in the context of the Internet Message Format (RFC 5322) and Multipurpose Internet Mail Extensions (MIME) (RFC 2045). This document obsoletes RFC 1036, providing an updated specification to reflect current practice and incorporating incremental changes specified in other documents. [STANDARDS-TRACK]
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.
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 30 must, 19 should, 5 may.
2.1 Base
- MUST NOTPublic" without the use of quotes, see Section 4.1 of [RFC5322]), but agents MUST NOT generate productions of such syntax.
- MUSTAgents conforming to this specification MUST generate only conformant articles.
2.2 Header Fields
- MUSTo All agents MUST generate header fields so that at least one space immediately follows the ':' separating the header field name and the header field body (for compatibility with deployed software, including NNTP [RFC3977] servers).
- MAYNews agents MAY accept header fields that do not contain the required space.
- MUSTo Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non- whitespace character.
- MUST NOTo Compliant software MUST NOT generate (but MAY accept) header field lines of more than 998 octets.
- MUSTWhere the use of non-ASCII characters is required, they MUST be encoded using the MIME mechanisms defined in [RFC2047] and [RFC2231].
2.3 MIME Conformance
- MUSTUser agents MUST meet the definition of MIME conformance in [RFC2049] and MUST also support [RFC2231].
- MAYUser agents MAY accept and generate other MIME extension header fields, and in particular SHOULD accept Content-Disposition [RFC2183] and Content-Language [RFC3282].
3 News Header Fields
- MUST NOTEach of these header fields MUST NOT occur more than once in a news article.
3.1 Mandatory Header Fields
- MUSTEach Netnews article conformant with this specification MUST have exactly one of each of the following header fields: Date, From, Message-ID, Newsgroups, Path, and Subject.
3.1.1 Date
- MUSTTherefore, agents MUST accept <date-time> constructs that use the "GMT" zone.
- MUST NOTNOTE: This specification does not change [RFC5322], which says that agents MUST NOT generate <date-time> constructs that include any zone names defined by <obs-zone>.
- SHOULDSoftware that accepts dates with unknown timezones SHOULD treat such timezones as equivalent to "-0000" when comparing dates, as specified in Section 4.3 of [RFC5322].
3.1.3 Message-ID
- MUST NOTThe <msg-id> MUST NOT be more than 250 octets in length.
- MUST NOTImplementations MUST NOT generate a Message-ID where the only difference from another Message-ID is the case of characters in the <id-right> part.
- SHOULDWhen generating a <msg-id>, implementations SHOULD use a domain name as the <id-right>.
3.1.4 Newsgroups
- SHOULD NOTOptional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
- SHOULD NOTA <component> SHOULD NOT consist solely of digits and SHOULD NOT contain uppercase letters.
- MAYSuch <component>s MAY be used only to refer to existing groups that do not conform to this naming scheme, but MUST NOT be used otherwise.
- SHOULD NOT<component>s beginning with underline ("_") are reserved for use by future versions of this standard and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages as defined by [RFC5537]).
- MUSTHowever, such names MUST be accepted by news servers.
- SHOULD NOT<component>s beginning with "+" and "-" are reserved for private use and SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages [RFC5537]) without a private prior agreement to do so.
- MUST NOTThe following <newsgroup-name>s are reserved and MUST NOT be used as the name of a newsgroup:
- MUST NOTThe following <newsgroup-name>s have been used for specific purposes in various implementations and protocols and therefore MUST NOT be used for the names of normal newsgroups.
- MAYThey MAY be used for their specific purpose or by local agreement.
3.2.3 Control
- MUST NOTAn article with a Control header field MUST NOT also have a Supersedes header field.
3.2.4 Distribution
- SHOULD NOT"world" indicates unlimited distribution and SHOULD NOT be used explicitly, since it is the default when the Distribution header field is absent entirely.
- MUST NOT"All" MUST NOT be used as a <dist-name>.
- SHOULD<dist-name>s SHOULD contain at least three characters, except when they are two-letter country codes drawn from [ISO3166-1].
- SHOULD NOTOptional FWS in the <dist-list> SHOULD NOT be generated, but MUST be accepted.
3.2.6 Followup-To
- SHOULD NOTThe Followup-To header field SHOULD NOT appear in a message, unless its content is different from the content of the Newsgroups header field.
- MUSTAgents MUST generate the keyword "poster" in lowercase, but MAY choose to recognize case- insensitive forms such as "Poster".
- SHOULD NOTAs in the Newsgroups (Section 3.1.4) header field, optional FWS in the <newsgroup-list> SHOULD NOT be generated, but MUST be accepted.
3.2.7 Injection-Date
- MUSTThis header field MUST be inserted whenever an article is injected.
- MUSTHowever, software that predates this standard does not use this header, and therefore agents MUST accept articles without the Injection-Date header field.
- MUST NOTAgents MUST NOT alter a pre-existing Date header field when adding an Injection- Date header field.
3.2.8 Injection-Info
- SHOULD NOTOther <attribute>s SHOULD NOT be used unless defined in extensions to this standard.
- MUSTIf non-standards-based <attribute>s are used, they MUST begin with an "x-".
- SHOULD NOTAlthough comments and folding of whitespace are permitted throughout the Injection-Info header field, folding SHOULD NOT be used within any <parameter>.
- SHOULDFolding SHOULD only occur before or after the ";" separating <parameter>s, and comments SHOULD only be used following the last <parameter>.
- SHOULDIn order to limit the exposure of personal data, it SHOULD be given in a form that cannot be interpreted by other sites.
- SHOULDHowever, to make it useful for rate limiting and abuse detection, two messages posted from the same source SHOULD have the same value of "posting-account", and two messages from different sources SHOULD have differing values of "posting-account".
3.2.10 References
- MUSTo The updated <msg-id> construct defined in Section 3.1.3 MUST be used.
- MUSTo Message identifiers MUST be separated with CFWS.
- SHOULD NOTo Comments in CFWS between message identifiers can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted.
3.2.13 User-Agent
- MAYThis header field MAY contain multiple <product> tokens identifying the user agent and any subproducts that form a significant part of it, listed in order of their significance for identifying the application.
3.3 Obsolete Header Fields
- MUST NOTThese header fields MUST NOT be generated and SHOULD be ignored.
3.3.1 Lines
- SHOULDAll agents SHOULD ignore it and SHOULD NOT generate it.
5 Security Considerations
- SHOULDTherefore, agents that generate message identifiers for Netnews articles SHOULD ensure that they are unpredictable.
7.2 Informative References
- REQUIREDo A SP (space) is REQUIRED after the colon (':') following a header field name.
- MUST NOTo The length of a <msg-id> MUST NOT exceed 250 octets.
- MUST* The <obs-phrase> construct MUST be accepted.
- MUST* The obsolete <zone> "GMT" MUST be accepted within a <date-time>.