RFC 5536
Netnews Article Format
RFC 5536: Netnews Article Format 🎀
Okay bestie, this is RFC 5536, and it's the spec for what a Netnews article actually looks like on the wire 📰✨ It's an Internet standards track document from November 2009, written by K. Murchison, Ed. (Carnegie Mellon University), C. Lindsey (University of Manchester), and D. Kohn (Healing Thresholds) 🫶 The big news is that it obsoletes RFC 1036, the old Netnews article spec, so this is the glow-up version. The title block doesn't list anything it updates, so that's all there is to it.
Abstract 💖
So the core idea is that this doc nails down the syntax of Netnews articles, using the Internet Message Format (RFC 5322) and MIME (RFC 2045) as the base. It replaces RFC 1036 so the spec matches how things are actually done now, and it folds in smaller changes from other docs too 💅
Status of This Memo 🦋
This is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🙈 For the current standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited, so share it with everyone 💜
Copyright Notice 🌈
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents 🍓
1. Introduction ....................................................4
1.1. Basic Concepts .............................................4
1.2. Scope ......................................................4
1.3. Requirements Notation ......................................4
1.4. Syntax Notation ............................................5
1.5. Definitions ................................................5
1.6. Structure of This Document .................................7
2. Format ..........................................................7
2.1. Base .......................................................7
2.2. Header Fields ..............................................8
2.3. MIME Conformance ...........................................9
3. News Header Fields ..............................................9
3.1. Mandatory Header Fields ...................................10
3.1.1. Date ...............................................11
3.1.2. From ...............................................11
3.1.3. Message-ID .........................................11
3.1.4. Newsgroups .........................................13
3.1.5. Path ...............................................14
3.1.6. Subject ............................................16
3.2. Optional Header Fields ....................................16
3.2.1. Approved ...........................................17
3.2.2. Archive ............................................17
3.2.3. Control ............................................17
3.2.4. Distribution .......................................18
3.2.5. Expires ............................................19
3.2.6. Followup-To ........................................19
3.2.7. Injection-Date .....................................20
3.2.8. Injection-Info .....................................20
3.2.9. Organization .......................................22
3.2.10. References ........................................22
3.2.11. Summary ...........................................23
3.2.12. Supersedes ........................................23
3.2.13. User-Agent ........................................23
3.2.14. Xref ..............................................24
3.3. Obsolete Header Fields ....................................25
3.3.1. Lines ..............................................25
4. Internationalization Considerations ............................25
5. Security Considerations ........................................25
6. IANA Considerations ............................................26
7. References .....................................................31
7.1. Normative References ......................................31
7.2. Informative References ....................................32
Appendix A. Acknowledgments ......................................34
Appendix B. Differences from RFC 1036 and Its Derivatives ........34
Appendix C. Differences from RFC 5322 ............................351. Introduction 🌸
1.1. Basic Concepts 🧚
"Netnews" is a set of protocols for generating, storing, and retrieving news "articles" (whose format is a subset of that for Email messages), and for exchanging them amongst a readership that is potentially widely distributed. It's organized around "newsgroups", with the expectation that each reader will be able to see all articles posted to each newsgroup in which they participate ✨ These protocols most commonly use a flooding algorithm, which propagates copies throughout a network of participating servers. Typically, only one copy is stored per server, and each server makes it available on demand to readers who are able to access that server 💅
1.2. Scope 🦋
Okay so this doc spells out the syntax of Netnews articles, based on the Internet Message Format [RFC5322] and MIME [RFC2045]. It obsoletes [RFC1036] and updates the article syntax to match current practice, pulling in changes and clarifications from other docs like [Son-of-1036] 🫶
This is the first in a set of docs that obsolete [RFC1036]. This one is all about the syntax and semantics of Netnews articles. [RFC5537] is also a Standards Track doc, and it covers the protocol side of Netnews articles without caring which transport is used, like the Network News Transfer Protocol (NNTP) [RFC3977]. [USEAGE], "Usenet Best Practice", has implementation recommendations for better interoperability and usability 🌈
This spec defines what article content format gets passed between systems. Lots of news systems store articles locally in this same format (which saves them from translating between formats), but local storage is outside the scope of this standard 💜
1.3. Requirements Notation 💖
Here's the key vocab 🔥 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
1.4. Syntax Notation 🎀
Header fields in this spec use the Augmented Backus-Naur Form (ABNF) notation (including the Core Rules) from [RFC5234], plus lots of constructs from [RFC5322], [RFC2045] as updated by [RFC2231], and [RFC3986]. Specifically, these are the borrowed bits:
token = <see RFC 2045 Section 5.1>
value = <see RFC 2045 Section 5.1>
parameter = <see RFC 2231 Section 7>
attribute = <see RFC 2231 Section 7>
FWS = <see RFC 5322 Section 3.2.2>
comment = <see RFC 5322 Section 3.2.2>
CFWS = <see RFC 5322 Section 3.2.2>
atext = <see RFC 5322 Section 3.2.3>
dot-atom-text = <see RFC 5322 Section 3.2.3>
phrase = <see RFC 5322 Section 3.2.5>
date-time = <see RFC 5322 Section 3.3>
mailbox = <see RFC 5322 Section 3.4>
mailbox-list = <see RFC 5322 Section 3.4>
address-list = <see RFC 5322 Section 3.4>
body = <see RFC 5322 Section 3.5>
fields = <see RFC 5322 Section 3.6>
IPv6address = <see RFC 3986 Section 3.2.2>
IPv4address = <see RFC 3986 Section 3.2.2>
ALPHA = <see RFC 5234 Appendix B.1>
CRLF = <see RFC 5234 Appendix B.1>
DIGIT = <see RFC 5234 Appendix B.1>
DQUOTE = <see RFC 5234 Appendix B.1>
SP = <see RFC 5234 Appendix B.1>
VCHAR = <see RFC 5234 Appendix B.1>Heads up, though: Section 3.1.3 gives a stricter definition of <msg-id> than the syntax in Section 3.6.4 of [RFC5322] 👀
1.5. Definitions 📖
Okay so, an "article" is the unit of Netnews, basically the Netnews version of an [RFC5322] "message" 💌. A "proto-article" is one that hasn't been injected into the news system yet. Unlike a real article, a proto-article might be missing some mandatory header fields 🙈.
A "message identifier" (Section 3.1.3) is a unique ID for an article 🆔. It's usually supplied by the user agent that posted it or, if that doesn't happen, by the "news server". It tells the article apart from every other article ever posted anywhere ✨. Articles with the same message identifier are treated as the same article, no matter how their body or header fields differ 🫶.
A "newsgroup" is a named forum meant for articles about one specific topic 💬. An article is "posted to" one newsgroup or several. When an article lands in more than one newsgroup, it's "crossposted" 🦋. That's NOT the same thing as posting the same text as separate articles, one per newsgroup, so keep that in mind, bestie!
A newsgroup can be "moderated" 👑. That means submissions don't get posted directly. Instead, they get mailed to a "moderator" who decides whether to post them. Moderators are usually humans, but they can be partly or fully software 🤖.
A "poster" is the person or software that writes a potentially compliant article and hands it to a user agent 💅.
A "reader" is the person or software reading Netnews articles 📖.
A "followup" is an article that responds to an earlier article, which is called its "precursor" 🔁. Every followup has a "References" header field that names that precursor. (But heads up: non-followup articles can have a References header field too 👀.)
A "control message" is an article marked as carrying control information. A news server that receives one may, depending on the policies at that site, do more than just file it and pass it along 🚨.
A news server is software that may accept articles from a user agent, and/or make articles available to user agents, and/or swap articles with other news servers 🖥️.
A "user agent" is software that may help posters turn proto-articles into something a news server can take, and/or fetch articles from a news server and show them to a reader, and/or help the reader write articles and followups 💌.
The generic term "agent" covers both user agents and news servers, and it's used when requirements apply to both 🧚.
An agent "generates" a construct if the construct didn't exist before the agent made it 🛠️. For example, a user agent might build a message out of text and addressing info a user typed in, or a news server might create an Injection-Info header field for a newly posted message ✨.
An agent "accepts" a construct if some other entity generated it and handed it over, and the agent processed it without treating it as a format or protocol error 🫶.
1.6. Structure of This Document 🗺️
This doc uses a cite-by-reference approach instead of copying the contents of other standards 📚. Copying could cause sneaky differences and interoperability headaches 😭. Even though this doc ends up pretty short because of that, you need a complete understanding of the normative references, and you need to implement them, in order to be compliant 🧠.
Section 2 defines the format of Netnews articles 📝. Section 3 details the header fields needed to make an article suitable for the Netnews environment 💖.
2. Format 📝
2.1. Base 🧱
An article is conformant to this spec if it follows the format in Section 3 of [RFC5322] and also the extra requirements of this spec 💯.
An article that uses the obsolete syntax from Section 4 of [RFC5322] is NOT conformant to this spec, except for the following two cases:
- Articles are conformant if they use the
<obs-phrase>construct (a phrase like "John Q. Public" written without quotes, see Section 4.1 of [RFC5322]), but agents MUST NOT generate productions of such syntax. - Articles are conformant if they use the "GMT"
<zone>, as specified in Section 3.1.1.
This document, and specifications that build on it, explain how to handle conformant articles 🤝. Handling non-conformant articles is outside the scope of this spec 🚫.
Agents conforming to this spec MUST generate only conformant articles 🙏.
The text below uses ABNF to restrict the syntax from [RFC5322]. This grammar is meant to be stricter than the [RFC5322] grammar. Articles need to conform to the ABNF in [RFC5322] AND to the restrictions here, both the ones written as text and the ones written as ABNF 📏.
NOTE: Other specs use "header" as a synonym for what [RFC5322] calls "header field". This document follows the terminology from Section 2 of [RFC5322], using "line", "header field", "header field name", "header field body", and "folding". The reason is that consistent terms across specs that depend on each other make them easier to use in the long run 🧠.
2.2. Header Fields 🏷️
All header fields in a Netnews article comply with [RFC5322]. This spec, however, is less permissive about what agents can generate and accept 🔒. The syntax for Netnews article headers is a strict subset of the Internet Message Format headers, so anything compliant with this spec is automatically compliant with [RFC5322] 💫. The reverse isn't guaranteed in every case, though 👀.
General rules for all header fields (even the ones documented in [RFC5322] and [RFC2045]) are listed below. Rules for specific header fields are in the relevant sections of this doc 📌.
- 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). News agents MAY accept header fields that do not contain the required space. - Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non-whitespace character.
NOTE: This means no header field body defined by or referenced by this document can be empty. So instead of the <unstructured> syntax from Section 3.2.5 of [RFC5322], this document uses a stricter definition:
unstructured = *WSP VCHAR *( [FWS] VCHAR ) *WSPNOTE: [RFC5322] sometimes uses[FWS]at the beginning or end of ABNF describing header field content. This spec uses*WSPin those cases, including where it redefines constructs from [RFC5322]. That's for consistency with the restriction above, but the restriction applies to all header fields, not just the ones where this doc defines the ABNF 🧐.
- Compliant software MUST NOT generate (but MAY accept) header field lines of more than 998 octets. This is the only limit on header field line length this standard sets. However, specific rules to the contrary may apply in particular cases (for example, under [RFC2047], lines of a header field containing encoded words are limited to 76 octets). [USEAGE] includes suggested limits for display convenience in user agents.
NOTE: As [RFC5322] says, there is NO restriction on the number of lines a header field can be split into. So there is NO restriction on the total length of a header field. In fact, with suitable folding, it can exceed the 998-octet limit that applies to a single header field line 🤯.
- The character set for header fields is US-ASCII. Where 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 🎀
User agents MUST meet the definition of MIME conformance in [RFC2049] and MUST also support [RFC2231]. This level of MIME conformance supports internationalization and multimedia in message bodies ([RFC2045], [RFC2046], and [RFC2231]), and internationalization of header fields ([RFC2047] and [RFC2231]). There are [Errata] for [RFC2045], [RFC2046], [RFC2047] and [RFC2231] right now, so note that too 📝.
For the purposes of Section 5 of [RFC2047], all header fields defined in Section 3 of this standard count as "extension message header fields". That permits the use of [RFC2047] encodings within any <unstructured> header field, or within any <comment> or <phrase> allowed in any structured header field 🧩.
User agents MAY accept and generate other MIME extension header fields. In particular, they SHOULD accept Content-Disposition [RFC2183] and Content-Language [RFC3282] 💖.
3. News Header Fields 📰
The following news header fields extend the ones defined in Section 3.6 of [RFC5322]:
fields =/ *( approved /
archive /
control /
distribution /
expires /
followup-to /
injection-date /
injection-info /
lines /
newsgroups /
organization /
path /
summary /
supersedes /
user-agent /
xref )Each of these header fields MUST NOT occur more than once in a news article 🚫.
The following header fields defined in this document don't allow <comment>s (they use FWS rather than CFWS) 💅:
ControlDistributionFollowup-ToLinesNewsgroupsPathSupersedesXref
This also applies to this header field defined in [RFC5322]:
Message-ID
Most of these header fields are mainly of interest to news servers, and news servers often need to process them super fast ⚡. So some header fields prohibit <comment>s 🏃♀️.
3.1. Mandatory Header Fields 🔑
Each Netnews article conformant with this spec MUST have exactly one of each of the following header fields: Date, From, Message-ID, Newsgroups, Path, and Subject 📋.
3.1.1. Date 📅
The Date header field is the same as the one in Sections 3.3 and 3.6.1 of [RFC5322], with the added restrictions detailed above in Section 2.2 💫. However, the use of "GMT" as a time zone (part of <obs-zone>) is deprecated, yet it's still super widespread in Netnews articles today 🙃. So agents MUST accept <date-time> constructs that use the "GMT" zone 🫶.
orig-date = "Date:" SP date-time CRLFNOTE: This spec doesn't change [RFC5322], which says agents MUST NOT generate<date-time>constructs that include any zone names defined by<obs-zone>🙅.
Software that accepts dates with unknown timezones SHOULD treat those timezones as equivalent to "-0000" when comparing dates, as specified in Section 4.3 of [RFC5322] 🕰️.
Also, these requirements apply wherever <date-time> is used, including Injection-Date and Expires (Sections 3.2.7 and 3.2.5, respectively) 🎉.
3.1.2. From 💌
okay so the From header field is literally the same as the one in Section 3.6.2 of [RFC5322], bestie, but with the extra restrictions from Section 2.2 layered on top 🎀 no surprises, just the same vibe with stricter rules ✨
from = "From:" SP mailbox-list CRLF3.1.3. Message-ID 🆔
the Message-ID header field holds a unique message identifier, and netnews is way more obsessed with identifier uniqueness and fast comparison than email is 💅 some news software and standards [RFC3977] might struggle with the full range of <msg-id>s that [RFC5322] allows, so this section narrows the syntax compared to Section 3.6.4 of [RFC5322] 🫶 the global uniqueness requirement for <msg-id> in [RFC5322] should be read as applying across every protocol that uses these identifiers, and across both Email and Netnews in particular 🌸
message-id = "Message-ID:" SP *WSP msg-id *WSP CRLF
msg-id = "<" msg-id-core ">"
; maximum length is 250 octets
msg-id-core = id-left "@" id-right
id-left = dot-atom-text
id-right = dot-atom-text / no-fold-literal
no-fold-literal = "[" *mdtext "]"
mdtext = %d33-61 / ; The rest of the US-ASCII
%d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\"the <msg-id> MUST NOT be more than 250 octets in length 🚫
NOTE: the length restriction makes sure that systems accepting message identifiers as a parameter when referencing an article (e.g., [RFC3977]) can count on a bounded length 🧚
just so we're clear, <msg-id> includes the < and > 💖
also, compared to the matching header field in [RFC5322], this one is different in a few ways 👀
- the syntax does not allow comments within the Message-ID header field.
- there is no possibility for ">" or WSP to occur inside a <msg-id>.
- even though they're commonly derived from <domain>s, <id-right>s are case-sensitive (and so, once created, they are not to be altered during subsequent transmission or copying) 😭
this is all to simplify processing for news servers and keep things interoperable with existing implementations and compliant with [RFC3977] 🫧 a simple comparison of octets will always be enough to tell whether two <msg-id>s are the same 🔥
also, this updated ABNF applies everywhere <msg-id> is used, including the References header field discussed in Section 3.2.10 and the Supersedes header field discussed in Section 3.2.12 🍓
some software matches the <id-right> of a <msg-id> case-insensitively, and some matches it case-sensitively, which is chaotic 💀 so implementations MUST NOT generate a Message-ID where the only difference from another Message-ID is the case of characters in the <id-right> part 🙈
when generating a <msg-id>, implementations SHOULD use a domain name as the <id-right> 🌈
NOTE: Section 3.6.4 of [RFC5322] recommends that the <id-right> be a domain name or a domain literal. domain literals are troublesome since lots of IP addresses aren't globally unique, while domain names are more likely to make unique Message-IDs 🧠
3.1.4. Newsgroups 📰
the Newsgroups header field tells you which newsgroup(s) the article is posted to 🦋
newsgroups = "Newsgroups:" SP newsgroup-list CRLF
newsgroup-list = *WSP newsgroup-name
*( [FWS] "," [FWS] newsgroup-name ) *WSP
newsgroup-name = component *( "." component )
component = 1*component-char
component-char = ALPHA / DIGIT / "+" / "-" / "_"not every server supports optional FWS in the list of newsgroups 😬 folding the Newsgroups header field over several lines has been shown to really hurt propagation, so optional FWS in the <newsgroup-list> SHOULD NOT be generated, but it MUST be accepted 🫶
a <component> SHOULD NOT consist solely of digits and SHOULD NOT contain uppercase letters 🙅♀️ such <component>s MAY be used only to refer to existing groups that don't follow this naming scheme, but MUST NOT be used otherwise 🚫
NOTE: all-digit <component>s clash with one widely used storage scheme for articles. mixed-case groups cause confusion between systems that match case-sensitively and systems that match case-insensitively 🥴
<component>s beginning with underline ("_") are reserved for future versions of this standard, so they SHOULD NOT be generated by user agents (whether in header fields or in newgroup control messages as defined by [RFC5537]) 🔮 however, such names MUST be accepted by news servers 💜
<component>s beginning with "+" and "-" are reserved for private use, so they 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 🤫 however, such names MUST be accepted by news servers 🌷
the following <newsgroup-name>s are reserved and MUST NOT be used as the name of a newsgroup 🛑
- groups whose first (or only) <component> is "example"
- the group "poster"
the following <newsgroup-name>s have been used for specific purposes in various implementations and protocols, so they MUST NOT be used for the names of normal newsgroups 🧃 they MAY be used for their specific purpose or by local agreement ✨
- groups whose first (or only) component is "to"
- groups whose first (or only) component is "control"
- groups that contain (or consist only of) the component "all"
- groups that contain (or consist only of) the component "ctl"
- the group "junk"
NOTE: "example." is reserved for examples in this and other standards. "poster" has a special meaning in the Followup-To header field. "to." is reserved for certain point-to-point communications together with the "ihave" control message defined in [RFC5537]. "control.*" and "junk" have special meanings in some news servers. "all" is used as a wildcard in some implementations, and "ctl" used to indicate a <control-command> within the Newsgroups header field, back in the day 🕰️
3.1.5. Path 🛤️
the Path header field shows the route an article has taken since it was injected into the Netnews system 🗺️ every agent that processes an article is required to prepend at least one <path-identity> to this header field body 🫡 this is mainly so news servers can avoid sending articles to sites already known to have them, especially the site they came from 🙅♀️ it also lets people gather statistics and trace the route articles take across the network 📊
path = "Path:" SP *WSP path-list tail-entry *WSP CRLF
path-list = *( path-identity [FWS] [path-diagnostic] "!" )
path-diagnostic = diag-match / diag-other / diag-deprecated
diag-match = "!" ; another "!"
diag-other = "!." diag-keyword [ "." diag-identity ] [FWS]
diag-deprecated = "!" IPv4address [FWS]
diag-keyword = 1*ALPHA ; see [RFC5537]
diag-identity = path-identity / IPv4address / IPv6address
tail-entry = path-nodot
; may be the string "not-for-mail"
path-identity = ( 1*( label "." ) toplabel ) / path-nodot
path-nodot = 1*( alphanum / "-" / "_" ) ; legacy names
label = alphanum [ *( alphanum / "-" ) alphanum ]
toplabel = ( [ label *( "-" ) ] ALPHA *( "-" ) label ) /
( label *( "-" ) ALPHA [ *( "-" ) label ] ) /
( label 1*( "-" ) label )
alphanum = ALPHA / DIGIT ; compare [RFC3696]a <path-identity> is a name identifying a site 🏠 it looks like a domain name with two or more components separated by dots, or a single name with no dots (<path-nodot>) 🧩
each <path-identity> in the <path-list> (which doesn't include the <tail-entry>) shows, from right to left, the agents the article has passed through, in order 🏃♀️ the <diag-match>, which shows up as "!!", means the agent on its left verified the identity of the agent on its right before accepting the article 🔐 (a <path-delimiter> "!" makes no such claim, so it's a different vibe entirely 🫢)
NOTE: historically, the <tail-entry> indicated the name of the sender. if it's not used for that, the string "not-for-mail" is often used instead, since at one point the whole path could be used as a mail address for the sender 📮
NOTE: even though <diag-keyword>s are case-insensitive, they're meant to be in uppercase so they stand out from the <path-identity>s, which are traditionally lowercase 🔠
a <path-diagnostic> is an item inserted into the Path header field for reasons other than naming a site 🩺 how these get used is described in [RFC5537] 📖
NOTE: one use of a <path-diagnostic> is to record an IP address. because <IPv6address>es are allowed, the colon (:) is permitted too 🙃 this can cause interoperability problems at older sites that treat ":" as a <path-delimiter> and have neighbors whose names are 4 or fewer characters, all valid HEX digits 😵💫
NOTE: <IPv4address>es have occasionally been used in the past (usually with a diagnostic intent), but their continued use is deprecated 🙅 they're still acceptable in the form of the <diag-deprecated> though 🫠
3.1.6. Subject 🎀
the Subject header field is the same as the one in Section 3.6.5 of [RFC5322], with the extra restrictions from Section 2.2 above 💅 more on what goes in the Subject header field is in [RFC5537] and [USEAGE] 📚
subject = "Subject:" SP unstructured CRLF3.2. Optional Header Fields 🌟
none of the header fields in this section are required to appear in every article, but some of them may be required in certain types of articles 🧁 more on those requirements is in [RFC5537] and [USEAGE] 🫶
the header fields Comments, Keywords, Reply-To, and Sender are used in Netnews articles in the same circumstances and with the same meanings as in [RFC5322], with the extra restrictions from Section 2.2 above 🍰 multiple occurrences of the Keywords header field are not permitted 🚫
comments = "Comments:" SP unstructured CRLF
keywords = "Keywords:" SP phrase *("," phrase) CRLF
reply-to = "Reply-To:" SP address-list CRLF
sender = "Sender:" SP mailbox CRLFthe MIME header fields MIME-Version, Content-Type, Content-Transfer-Encoding, Content-Disposition, and Content-Language are used in Netnews articles in the same circumstances and with the same meanings as in [RFC2045], [RFC2183], and [RFC3282], with the extra restrictions from Section 2.2 above 🎨
all the remaining news header fields are described below 👇
3.2.1. Approved ✅
the Approved header field gives the mailing addresses (and maybe the full names) of the people or entities approving the article for posting 🫡 its main uses are in moderated articles and in group control messages, so check [RFC5537] for those 👑
approved = "Approved:" SP mailbox-list CRLF3.2.2. Archive 📚✨
okay so the Archive header is basically the poster saying "should this be saved forever or nah?" 🦋 It shows what the poster intends about keeping the article in publicly accessible long-term or permanent storage.
archive = "Archive:" SP [CFWS] ("no" / "yes")
*( [CFWS] ";" [CFWS] archive-param ) [CFWS] CRLF
archive-param = parameterA field body of "no" means the poster does not want publicly accessible long-term or permanent archives to redistribute the article. A field body of "yes" means the poster is totally fine with that redistribution 💅
NOTE: No <parameter>s are defined yet, so if you see any, you can just ignore them 🙈
More discussion about how to use this one is in [USEAGE] 📖
3.2.3. Control 🎛️
the Control header is how an article announces that it's a control message 🤖 It also says which actions should happen, on top of the usual storing and/or relaying stuff.
control = "Control:" SP *WSP control-command *WSP CRLF
control-command = verb *( 1*WSP argument )
verb = token
argument = 1*( %x21-7E )The verb says what action to take, and the argument(s) (if there are any) give the details 🧚 Sometimes the <body> (as defined in [RFC5322]) of the article has extra details too. All the legal verbs and their arguments live in the companion document, [RFC5537] 📚
An article with a Control header field MUST NOT also have a Supersedes header field. Not both, bestie 🚫
3.2.4. Distribution 🌍
the Distribution header is how you limit where an article travels, either by geography or by organization 🗺️
distribution = "Distribution:" SP dist-list CRLF
dist-list = *WSP dist-name
*( [FWS] "," [FWS] dist-name ) *WSP
dist-name = ALPHA / DIGIT
*( ALPHA / DIGIT / "+" / "-" / "_" )The <dist-name>s "world" and "local" are reserved 🔒 "world" means unlimited distribution, and it SHOULD NOT be used explicitly, since it's already the default when the Distribution header field is absent entirely 🌎 "local" is reserved for sending only to the local site, as your local software config defines it 🏠
"All" MUST NOT be used as a <dist-name>. <dist-name>s SHOULD contain at least three characters, unless they're two-letter country codes from [ISO3166-1] 🇺🇳 <dist-name>s are case-insensitive, so "US", "Us", "uS", and "us" all mean the exact same thing 💖
Optional FWS in the <dist-list> SHOULD NOT be generated, but it MUST be accepted 🫶
3.2.5. Expires ⏰
the Expires header is the poster's "okay, this stops being relevant at this time, you can delete it" date and time ✂️
expires = "Expires:" SP date-time CRLFCheck the remarks under Section 3.1.1 for the syntax of <date-time> and the requirements and recommendations it has to follow 📅
NOTE: This header is super useful when the poster wants an unusually long or unusually short expiry time 🍓
NOTE: Expires also shows up sometimes in Email with a similar meaning, see [RFC2156] 💌
3.2.6. Followup-To 💬
the Followup-To header says which newsgroup(s) the poster wants followups posted to 📮 The Followup-To header field SHOULD NOT appear in a message, unless its content is different from the Newsgroups header field 🙅
followup-to = "Followup-To:" SP ( newsgroup-list / poster-text )
CRLF
poster-text = *WSP %d112.111.115.116.101.114 *WSP
; "poster" in lowercaseThe syntax is the same as the Newsgroups (Section 3.1.4) header field, with one twist 🌸 The keyword "poster" means followups should be emailed straight to the article's poster (using the Reply-To addresses if there are any, otherwise the From addresses) instead of being posted to any newsgroups 💜
Agents MUST generate the keyword "poster" in lowercase, but they MAY choose to recognize case-insensitive forms like "Poster" 🙌
Like 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 💉
the Injection-Date header has the date and time the article got injected into the network 🚀 Its whole purpose is to help news servers check for "stale" articles using a <date-time> that a news server added at injection time, instead of the one the user agent added when the message was composed 🕰️
This header field MUST be inserted whenever an article is injected. However, software from before this standard doesn't use this header, so agents MUST accept articles without the Injection-Date header field 🫶
injection-date = "Injection-Date:" SP date-time CRLFCheck the remarks under Section 3.1.1 for the syntax of <date-time> and the requirements and recommendations it has to follow 📅
NOTE: Clocks on different agents aren't always synced, so the <date-time> here might not be later than the one in the Date header field. Agents MUST NOT alter a pre-existing Date header field when adding an Injection-Date header field 👀
This header is meant to replace the "NNTP-Posting-Date" header, which was used but never documented. That one is now deprecated 🪦
3.2.8. Injection-Info 🕵️♀️
the Injection-Info header is info from the injecting news server about how the article got into the Netnews system 🔍 It helps trace the article's true origin, and it can also list addresses where complaints about the poster can go 📬
injection-info = "Injection-Info:" SP [CFWS] path-identity
[CFWS] *( ";" [CFWS] parameter ) [CFWS] CRLFNOTE: The syntax of <parameter> (Section 5.1 of [RFC2045], as amended by [RFC2231]), read together with the folding rules of [RFC0822] (not [RFC2822] or [RFC5322]), effectively lets [CFWS] show up on either side of the "=" inside a <parameter> 🎀
Here's the table of each <attribute> and the format of its <value> for each <parameter> defined for this header. At most, one occurrence of each such <parameter> is allowed 📋
<attribute> format of <value>
-------------------- -----------------
"posting-host" a <host-value>
"posting-account" any <value>
"logging-data" any <value>
"mail-complaints-to" an <address-list>where
host-value = dot-atom-text / IPv4address / IPv6address /
(dot-atom-text ":" ( IPv4address / IPv6address ))NOTE: Since any such <host-value> or <address-list> also has to be a valid <value>, you'll usually need to wrap it in a <quoted-string>, for example: posting-host = "posting.example.com:192.0.2.1"
Other <attribute>s SHOULD NOT be used unless they're defined in extensions to this standard. If non-standards-based <attribute>s are used, they MUST begin with an "x-" 🧩
Comments and folding of whitespace are allowed all throughout the Injection-Info header field, but folding SHOULD NOT be used within any <parameter> 🙃 Folding SHOULD only happen before or after the ";" separating <parameter>s, and comments SHOULD only go after the last <parameter> 💅
NOTE: Some of this info used to be sent in non-standardized headers like NNTP-Posting-Host, X-Trace, X-Complaints-To, and others. Once a news server generates an Injection-Info header field, it should have no need to send these non-standard header fields 🧹
The "posting-host" <parameter> specifies the Fully Qualified Domain Name (FQDN) and/or IP address (IPv4address or IPv6address) of the host the news server received the article from 🖥️
NOTE: If the "posting-host" <parameter> can't deterministically identify the host (for example, with dynamic IP address allocation), the "posting-account" or "logging-data" <parameter> may give more info about the true origin of the article 🔎
The "posting-account" <parameter> identifies the source the news server got the article from, written in a notation the news server administrator can interpret. It can include whatever info the administrator thinks is relevant 🗝️ To limit exposure of personal data, it SHOULD be given in a form that other sites can't interpret. But to make it useful for rate limiting and abuse detection, two messages posted from the same source SHOULD have the same "posting-account" value, and two messages from different sources SHOULD have different values 🚦 What counts as a "source" is up to the news server administrator 🫡
The "logging-data" <parameter> holds info (usually a session number or some other non-persistent way of identifying a posting account) that lets you figure out the true origin of the article by checking the news server's logs 🪵
The "mail-complaints-to" <parameter> lists one or more mailboxes for complaints about the poster's behavior 📨
Which of these <parameter>s to include is a matter of local policy 🌈 Some of the info has privacy implications, which is covered in [USEAGE] 🔐
3.2.9. Organization 🏢
the Organization header is a short phrase naming the poster's organization 💼
organization = "Organization:" SP unstructured CRLFNOTE: There is no "s" in Organization 😭
3.2.10. References 🔗
the References header is the same as the one in Section 3.6.4 of [RFC5322], plus the extra restrictions from Section 2.2 above and these ones 🧵
- The updated <msg-id> construct defined in Section 3.1.3 MUST be used.
- Message identifiers MUST be separated with CFWS.
- Comments in CFWS between message identifiers can cause interoperability problems, so comments SHOULD NOT be generated but MUST be accepted.
references = "References:" SP [CFWS] msg-id *(CFWS msg-id)
[CFWS] CRLF3.2.11. Summary 📝
the Summary header is a short phrase that sums up what the article is about ✨
summary = "Summary:" SP unstructured CRLF3.2.12. Supersedes 🔄
the Supersedes header holds a message identifier for an article that gets superseded when this one arrives 🫣 An article with a Supersedes header is basically the same as a "cancel" [RFC5537] control message for that article, followed right away by the new article without the Supersedes header 🎬
supersedes = "Supersedes:" SP *WSP msg-id *WSP CRLFNOTE: There is no "c" in Supersedes 💀
NOTE: The Supersedes header defined here has nothing to do with the Supersedes header that sometimes shows up in Email messages converted from X.400 according to [RFC2156] 🙅♀️ Specifically, the syntax here only allows one <msg-id>, while that Email version allows multiple <msg-id>s 🫶
3.2.13. User-Agent 🕵️
okay so the User-Agent header field tells everyone which user agent (usually a newsreader) wrote the article 💅 it's for stats, and also for tracking down standards violations back to the exact software that needs fixing 🔧 fr, it's basically the app's name tag. and it's meant to be usable in Email too 💌 no cap, very versatile
user-agent = "User-Agent:" SP 1*product [CFWS] CRLF
product = [CFWS] token [ [CFWS] "/" product-version ]
product-version = [CFWS] tokenthis header field MAY contain multiple <product> tokens that identify the user agent plus any subproducts that are a big part of it 🌸 they're listed in order of how much they help identify the app, so the most important one goes first ✨
NOTE: some of this info used to get sent in non-standard header fields like X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent, and a bunch of others 🙈 once a user agent makes a User-Agent header field, it should have no need to send those non-standard ones anymore. bestie, one header to rule them all 👑
NOTE: [RFC2616] has a similar thing for HTTP 🦋 the Netnews format is a little different though: "{" and "}" are allowed inside tokens (<product> and <product-version>), and comments are allowed anywhere whitespace is 🎀
3.2.14. Xref 🗂️
the Xref header field shows where an article got filed by the last news server that processed it 📍 user agents use this a lot to avoid processing crossposted articles more than once, which is so smart 🧠🫶
xref = "Xref:" SP *WSP server-name
1*( FWS location ) *WSP CRLF
server-name = path-identity
location = newsgroup-name ":" article-locator
article-locator = 1*( %x21-27 / %x29-3A / %x3C-7E )
; US-ASCII printable characters
; except '(' and ';'the <server-name> is included so software can tell which news server made the header field 🖥️ the locations say where the article is filed, meaning which newsgroups (these might be different from the ones in the Newsgroups header field) and where inside those newsgroups 📂 the exact form of an <article-locator> is up to each implementation, so no single format is mandatory 🤷♀️
NOTE: the traditional form of an <article-locator> (as required by [RFC3977]) is a decimal number, with articles in each newsgroup numbered consecutively starting from 1. classic vibes 🔢💜
3.3. Obsolete Header Fields 🪦
the header fields Date-Received, Posting-Version, and Relay-Version from [RFC0850], plus Also-Control, Article-Names, Article-Updates, and See-Also from [Son-of-1036], are officially obsolete 💀 if you want to know how they used to work, check out those original spec documents 📚
these header fields MUST NOT be generated and SHOULD be ignored 🚫 no more making them, and if you see one, just let it slide 🙈
3.3.1. Lines 📏
the Lines header field tells you how many lines are in the <body> (as defined in [RFC5322]) of the article 📝
lines = "Lines:" SP *WSP 1*DIGIT *WSP CRLFthe line count is the number of CRLF separators in the <body> 🔢
historically this header field was used by the NNTP [RFC3977] overview facility, but that use is now deprecated 😬 so it's considered obsolescent, and it's likely to get removed completely in a future version of this standard 👋 all agents SHOULD ignore it and SHOULD NOT generate it 🫠
4. Internationalization Considerations 🌍
internationalization of Netnews article header fields and bodies is handled with the MIME mechanisms covered in Section 2.3 🌈 heads up though: how to generate internationalized <newsgroup-name>s for use in header fields is NOT covered in this document, so that one's a mystery for now 🕵️♀️
5. Security Considerations 🔐
the Netnews article format in this document does NOT provide any security services, like confidentiality, authentication of the sender, or non-repudiation 😱 bestie, that's a big deal. those services have to be layered on top with protocols like S/MIME [RFC3851] or PGP/MIME (Pretty Good Privacy / MIME) [RFC3156], or underneath, using secure versions of the news transport protocols 🛡️ also, a bunch of currently non-standardized protocols like [PGPVERIFY] might get standardized soon 👀
message identifiers (Section 3.1.3) in Netnews articles are required to be unique, and articles may be refused (during server-to-server transfer) if their identifier has already been seen 🚨 if a malicious agent can predict an article's identifier, it can preempt the article by posting its own article (maybe to a totally different group) with the same message identifier, which stops the target article from propagating 💔 that's a whole villain arc 😤 so agents that generate message identifiers for Netnews articles SHOULD ensure that they are unpredictable 🔒✨
MIME security considerations are discussed in [RFC2046] 📎 the full range of encodings allowed for parameters in [RFC2046] and [RFC2231] lets in constructs that simple parsers might fail to parse correctly 🙃 examples of hard-to-parse constructs are:
Content-Type: multipart/mixed
(; boundary=foo ; xyz=");bOuNdArY*=''next%20part(")
Content-Type: multipart/digest;
boundary (not=me) = ("yes ;-) simple (foo;bar") ; x-foo = xyzzysuch parsing deficiencies may be used as part of an attack. 🚨😭 parsers, please be careful out there 💖
further security considerations are discussed in [RFC5537] 🎀
6. IANA Considerations ✨
okay so IANA is the org that keeps the official lists of protocol stuff, and bestie, they've gotten these netnews header fields registered in the Permanent Message Header Field Repository 📚🦋 which is just the official list. They did it following the rules in [RFC3864], which is giving very organized, very on brand 💅
Here's the whole registry entry list, every single one, no skipping 🌸 Some are still standard, some are deprecated, and some are obsoleted (aka retired, RIP 🕯️). Check the Specification document(s) column to see where each one is actually defined.
Header field name: Also-Control
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.15)
Header field name: Approved
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.1)
Header field name: Archive
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.2)
Header field name: Article-Names
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.17)
Header field name: Article-Updates
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.18)
Header field name: Comments
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC5322] (Section 3.6.5)
Header field name: Control
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.3)
Header field name: Date
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.1),
[RFC5322] (Section 3.6.1)
Header field name: Date-Received
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.2.4)
Header field name: Distribution
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.4)
Header field name: Expires
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.5)
Header field name: Followup-To
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.6)
Header field name: From
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.2),
[RFC5322] (Section 3.6.2)
Header field name: Injection-Date
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.7)
Header field name: Injection-Info
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.8)
Header field name: Keywords
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC5322] (Section 3.6.5)
Header field name: Lines
Applicable protocol: netnews
Status: deprecated
Author/change controller: IETF
Specification document(s): This document (Section 3.3.1)
Related information: [RFC3977] (Section 8.1)
Header field name: Message-ID
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.3)
Related information: [RFC5322] (Section 3.6.4)
Header field name: Newsgroups
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.4)
Header field name: NNTP-Posting-Date
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): none
Header field name: NNTP-Posting-Host
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC2980] (Section 3.4.1)
Header field name: Organization
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.9)
Header field name: Path
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.5)
Header field name: Posting-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.2)
Header field name: References
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.10),
[RFC5322] (Section 3.6.4)
Header field name: Relay-Version
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [RFC0850] (Section 2.1.1)
Header field name: Reply-To
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC5322] (Section 3.6.2)
Header field name: See-Also
Applicable protocol: netnews
Status: obsoleted
Author/change controller: IETF
Specification document(s): [Son-of-1036] (Section 6.16)
Header field name: Sender
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2),
[RFC5322] (Section 3.6.2)
Header field name: Subject
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.1.6),
[RFC5322] (Section 3.6.5)
Header field name: Summary
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.11)
Header field name: Supersedes
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.12)
Header field name: User-Agent
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.13)
Related information: [RFC2616] (Section 14.43)
Header field name: Xref
Applicable protocol: netnews
Status: standard
Author/change controller: IETF
Specification document(s): This document (Section 3.2.14)7. References 📚
7.1. Normative References
These are the must-read refs, the ones the whole spec leans on 🫶 Here's the full list, all details included:
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header Extensions for
Non-ASCII Text", RFC 2047, November 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183,
August 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and
Encoded Word Extensions: Character Sets, Languages,
and Continuations", RFC 2231, November 1997.
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282,
May 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
"Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, January 2005.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[RFC5537] Allbery, R., Ed. and C. Lindsey, "Netnews Architecture
and Protocols", RFC 5537, November 2009.7.2. Informative References
These ones are the extra reading 🌈 Not required, but so good for going deeper 🧚
[Errata] "RFC Editor Errata",
<http://www.rfc-editor.org/errata.php>.
[ISO3166-1] International Organization for Standardization, "ISO
3166-1:1997. Codes for the representation of names of
countries and their subdivisions -- Part 1: Country
codes", 1997.
[PGPVERIFY] Lawrence, D., "Authentication of Usenet Group Changes
(pgpverify)", June 1999,
<ftp://ftp.isc.org/pub/pgpcontrol/README.html>.
[RFC0822] Crocker, D., "Standard for the format of ARPA Internet
text messages", STD 11, RFC 822, August 1982.
[RFC0850] Horton, M., "Standard for interchange of USENET
messages", RFC 850, June 1983.
[RFC1036] Horton, M. and R. Adams, "Standard for interchange of
USENET messages", RFC 1036, December 1987.
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME",
RFC 2156, January 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC2980] Barber, S., "Common NNTP Extensions", RFC 2980,
October 2000.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T.
Roessler, "MIME Security with OpenPGP", RFC 3156,
August 2001.
[RFC3696] Klensin, J., "Application Techniques for Checking and
Transformation of Names", RFC 3696, February 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message
Specification", RFC 3851, July 2004.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004.
[RFC3977] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006.
[Son-of-1036] Spencer, H., "Son of 1036: News Article Format and
Transmission", Work in Progress, May 2009.
[USEAGE] Lindsey, C., "Usenet Best Practice", Work in Progress,
March 2005.Appendix A. Acknowledgments 🫶
Okay bestie, this doc was an eight-year effort 😭 so there are way too many people who helped make it to name one by one. Huge thanks to all the past and present members of the USEFOR Working Group of the Internet Engineering Task Force (IETF) and its accompanying mailing list 💖
Appendix B. Differences from RFC 1036 and Its Derivatives 🎀
This appendix is the tea ☕ on what changed in the Netnews article format compared to earlier standards, specifically [RFC1036].
- The [RFC5322] conventions for parenthesis-enclosed
<comment>s in header fields are supported in all newly defined header fields and in header fields inherited from [RFC5322]. They're still disallowed though, for performance and/or compatibility reasons, in the Control, Distribution, Followup-To, Lines, Message-ID, Newsgroups, Path, Supersedes, and Xref header fields. 🙈 - Multiple addresses are allowed in the From header field. 💌
- [FWS] is permitted in Newsgroups header fields. ✨
- An enhanced syntax for the Path header field lets the injection point of, and the route taken by, an article be determined with more precision. 🛤️
- Only one (1) message identifier is allowed in the Supersedes header field. 🫠
- MIME is recognized as an integral part of Netnews. 💅
- There's a new Injection-Date header field to make the rejection of stale articles more precise and to minimize spurious rejections. 🧚
- There are several new optional header fields defined, notably Archive, Injection-Info, and User-Agent, so the functionality goes up big time 📈
- Certain header fields, notably Lines, have been deprecated or made obsolete (Section 3.3). 🥀
- The convention to interpret subjects starting with the word "cmsg" as a control message was removed. 🗑️
- There are numerous other small changes, clarifications, and enhancements. 🌈
Appendix C. Differences from RFC 5322 🦋
This appendix lists the differences between the syntax allowed by the Netnews article format (this document) and the Internet Message Format, as specified in [RFC5322].
The Netnews article format is a strict subset of the Internet Message Format, so all Netnews articles conform to the syntax of [RFC5322]. Periodt 💯
The following restrictions are important:
- A SP (space) is REQUIRED after the colon (':') following a header field name. 👀
- A slightly restricted syntax of
<msg-id>(to be used by the Message-ID, References, and Supersedes header fields) is defined. 🔐 - The length of a
<msg-id>MUST NOT exceed 250 octets. 🚫 - Comments are not allowed in the Message-ID header field. 🙅♀️
- The CFWS between
<msg-id>s in the References header field is not optional. 💜 - It is legal for a parser to reject obsolete syntax, except that:
- The
<obs-phrase>construct MUST be accepted. 🫶 - The obsolete
<zone>"GMT" MUST be accepted within a<date-time>. 🕐
- The
- Every line of a header field body (including the first and any that are subsequently folded) MUST contain at least one non-whitespace character. This means that an empty header field body is illegal. 🙃
Authors' Addresses ✨
Kenneth Murchison (editor)
Carnegie Mellon University
5000 Forbes Avenue
Cyert Hall 285
Pittsburgh, PA 15213
U.S.A.
Phone: +1 412 268 2638
EMail: murch@andrew.cmu.edu
Charles H. Lindsey
University of Manchester
5 Clerewood Avenue
Heald Green
Cheadle
Cheshire SK8 3JU
U.K.
Phone: +44 161 436 6131
EMail: chl@clerew.man.ac.uk
Dan Kohn
Healing Thresholds
211 N End Ave Apt 22E
New York, NY 10282
U.S.A.
Phone: +1 415 233 1000
EMail: dan@dankohn.com📦 where this page comes from
- ietf: rfc5536 2009-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms