RFC 850
Standard for interchange of USENET messages
RFC 850: Standard for Interchange of USENET Messages 💖
RFC 850, dated June 1983, by Mark R. Horton 🎀
Status: this memo was distributed as an RFC only so researchers in the ARPA community could find the info easily. It does not specify an Internet standard 🫶 The title block doesn't list anything it obsoletes or updates.
1. Introduction ✨
okay so this doc defines the standard format for swapping Network News articles between USENET sites 📰 It explains what the articles themselves look like, and gives partial standards for how news gets sent around. The transmission side is intentionally not fully standardized 🦋 That gives individual hosts lots of freedom to pick their own transmission hardware and software, decide whether to batch news, and so on. main character energy for flexibility 💅
There are five sections in this doc. Section two defines the format. Section three defines the valid control messages. Section four specifies some valid transmission methods. Section five describes the overall news propagation algorithm 🌸
2. Article Format 📝
the main goal when picking an article format was making it fit in with existing tools as well as possible 💜 Existing tools include both mail and news implementations. (The notesfiles system from the University of Illinois counts as a news implementation, fyi 🙈) A standard format for mail messages had already existed on the ARPANET for years, and it covers most of what USENET needs. The ARPANET format is extensible, so the extra stuff USENET needs can be added inside the ARPANET standard without any drama ✨
so the rule is that every USENET news article must be formatted as a valid ARPANET mail message, following the ARPANET standard RFC 822 🔥 This standard is more restrictive than the ARPANET one. It adds requirements to each article and forbids certain ARPANET features. BUT it should always be possible to use a tool that expects an ARPANET message to process a news article, so it's still compatible 🧚 If this standard ever conflicts with the ARPANET standard, RFC 822 is the one that's correct and this standard is the one that's wrong 💀
- 1 -An example message is included below to show off the fields 🎀
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.general
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19-Nov-82 16:14:55 EST
Followup-To: net.news
Expires: Saturday, 1-Jan-83 00:00:00 EST
Date-Received: Friday, 19-Nov-82 16:59:30 EST
Organization: Bell Labs, Murray Hill
The body of the article comes here, after a blank line.Here's an example of a message in the old format (from before this standard existed) 🕰️ It's recommended that implementations also accept articles in this format, to make upward conversion easier 🫶
From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
Newsgroups: net.general
Title: Usenet Etiquette -- Please Read
Article-I.D.: eagle.642
Posted: Fri Nov 19 16:14:55 1982
Received: Fri Nov 19 16:59:30 1982
Expires: Mon Jan 1 00:00:00 1990
The body of the article comes here, after a blank line.Some news systems send news in the "A" format, which looks like this 👀
Aeagle.642
net.general
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
The body of the article comes here, with no blank line.An article is made of several header lines, then a blank line, then the body of the message 💌 Each header line has a keyword, a colon, a blank, and some extra info. This is a subset of the ARPANET standard, simplified so simpler software can handle it 🧸 The "from" line may optionally include a full name, in the format above, or use the ARPANET angle bracket syntax. To keep implementations simple, other formats (for example, with part of the machine address after the close parenthesis) are not allowed 🙅♀️ The ARPANET convention of continuation header lines (starting with a blank or tab) is allowed 🌈
Certain headers are required and certain headers are optional 💅 Any unrecognized headers are allowed, and they'll be passed through unchanged 🦋 The required headers are Relay-Version, Posting-Version, From, Date, Newsgroups, Subject, Message-ID, and Path 👑 The optional headers are Followup-To, Date-Received, Expires, Reply-To, Sender, References, Control, Distribution, and Organization ✨
2.1 Required Headers 🎀
2.1.1 Relay-Version 🚀
This header line shows the version of the program responsible for sending this article over the immediate link. That's the program relaying the article from the next site 💖 For example, say site A sends an article to site B, and site B forwards it to site C. The message going from A to B would have a Relay-Version header identifying the program running on A, and the message going from B to C would identify the program running on B 🫶 This header can be used to interpret older headers in an upward compatible way ✨ Relay-Version must always be the first in a message, so all articles meeting this standard will begin with an upper case "R" 🔥 No other restrictions are placed on the order of header lines 🌸
The line has two fields, separated by semicolons. The fields are the version and the full domain name of the site 💜 The version should identify the system program used (e.g., "B") as well as a version number and version date. For example, the header line might contain
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCPThis header should not be passed on to additional sites 🙈 A relay program, when passing an article on, should include only its own Relay-Version, not the Relay-Version of some other site 🧚 (For upward compatibility with older software: if a Relay-Version is found in a header that isn't the first line, it should be assumed to have been moved by an older version of news and deleted 💀)
2.1.2 Posting-Version 📮
This header identifies the software responsible for entering this message into the network 💌 It has the same format as Relay-Version 🎀 It will normally identify the same site as the Message-ID, unless the posting site is acting as a gateway for a message that already contains a message ID generated by mail 🌈 (A gateway is allowed to use an externally generated message ID, but the message ID should be checked to make sure it conforms to this standard and to RFC 822 🫶)
- 3 -2.1.3 From 💖
The From line contains the electronic mailing address of the person who sent the message, in the ARPA internet syntax 📬 It may optionally also contain the full name of the person, in parentheses, after the electronic address 🎀 The electronic address is the same as the entity responsible for originating the article, unless the Sender header is present. In that case the From header might not be verified 👀
Note that in all site and domain names, upper and lower case are considered the same. So mark@cbosgd.UUCP, mark@cbosgd.uucp, and mark@CBosgD.UUcp are all equivalent 💅 User names may or may not be case sensitive. For example, Billy@cbosgd.UUCP might be different from BillY@cbosgd.UUCP 🙃 Programs should avoid changing the case of electronic addresses when forwarding news or mail 🫶
RFC 822 specifies that all text in parentheses is to be interpreted as a comment 💭 It's common in ARPANET mail to put the user's full name in a comment at the end of the From line 🌸 This standard specifies a more rigid syntax 🔒 The full name is not considered a comment. It's an optional part of the header line 🦋 Either the full name is omitted, or it appears in parentheses after the electronic address of the person posting the article, or it appears before an electronic address enclosed in angle brackets. So the three permissible forms are:
From: mark@cbosgd.UUCP
From: mark@cbosgd.UUCP (Mark Horton)
From: Mark Horton <mark@cbosgd.UUCP>Full names may contain any printing ASCII characters from space through tilde 🌈 The exceptions are that they may not contain parentheses "(" or ")", or angle brackets "<" or ">" 🙅♀️ Additional restrictions may be placed on full names by the mail standard. In particular, the characters comma ",", colon ":", and semicolon ";" are inadvisable in full names 🙈
2.1.4 Date 🗓️
The Date line (formerly "Posted") is the date the article was originally posted to the network 🌟 It has to be in a format that's acceptable to both the ARPANET and to the getdate routine. This date stays unchanged as the article gets propagated throughout the network ✨ One format that's acceptable to both is
Weekday, DD-Mon-YY HH:MM:SS TIMEZONESeveral examples of valid dates appear in the sample article above 🎀 Note in particular that ctime format:
Wdy Mon DD HH:MM:SS YYYYis not acceptable, because it isn't a valid ARPANET date 💀 However, since older software still generates this format, news implementations are encouraged to accept it and translate it into an acceptable format 🫶
- 4 -The TIMEZONE field is currently subject to worldwide time zone abbreviations 🌍 That includes the usual American zones (PST, PDT, MST, MDT, CST, CDT, EST, EDT), the other North American zones (Bering through Newfoundland), European zones, Australian zones, and so on 🦘 There isn't a complete list yet, and it's not clear an unambiguous list even exists 🤷♀️ So software authors are encouraged to keep this code flexible. In particular, they should not assume time zone names are exactly three letters long 🙈 Implementations are free to edit this field, keeping the time the same but changing the time zone to a known one (with an appropriate adjustment to the local time shown) 🔥
2.1.5 Newsgroups 📰
The Newsgroups line specifies which newsgroup or newsgroups the article belongs in 💜 You can list multiple newsgroups, separated by a comma. The newsgroups specified must all be the names of existing newsgroups, since posting to them won't create any new ones 🚫
Wildcards (for example, the word "all") are never allowed in a Newsgroups line 🙅♀️ So a newsgroup called "net.all" is illegal, although a newsgroup named "net.sport.football" is totally permitted 🏈
If an article is received with a Newsgroups line listing some valid newsgroups and some invalid ones, a site should not remove the invalid newsgroups from the list 🫶 Instead, the invalid newsgroups should be ignored 👀 For example, suppose site A subscribes to the classes "btl.all" and "net.all," and exchanges news articles with site B. Site B subscribes to "net.all" but not "btl.all" 🌸 Suppose A receives an article with "Newsgroups: net.micro,btl.general". This article gets passed on to B, because B receives net.micro, but B doesn't receive btl.general 🧚 A must leave the Newsgroup line unchanged. If it removed "btl.general," the edited header could eventually re-enter the "btl.all" class. That would result in an article that isn't shown to users subscribing to "btl.general" 😭 Also, followups from outside "btl.all" wouldn't be shown to those users either 💔
- 5 -2.1.6 Subject 💌
The Subject line (formerly "Title")
So the Subject line tells everyone what the article is about 👀 It should give enough of a hint about the contents that a reader can decide whether to open it just from the subject 💅 If the article is a reply to another article (aka a "followup"), the default subject should start with the four characters Re: and the References line is required 🫶 (Users might want to tweak the subject of their followup, but the default should still start with Re: .) ✨
2.1.7 Message-ID 🆔
The Message-ID line gives each article its own unique ID 🔑 The same message ID may not be reused during the lifetime of any article with that same message ID 🙅♀️ (It is recommended that no message ID be reused for at least two years.) 🗓️ Message IDs follow this syntax:
"<" "string not containing blank or >" ">"To stay in line with RFC 822, the Message-ID must use this format:
"<" "unique" "@" "full domain name" ">"Here, "full domain name" is the full name of the host where the article first entered the network, including the domain that host lives in 🏠 And "unique" can be any string of printing ASCII characters, as long as it doesn't include "<", ">", or "@" 🧩 For example, the "unique" part could be an integer that works as a sequence number for articles submitted to the network, or a short string made from the date and time the article was created 📅 So a valid message ID for an article submitted from site ucbvax in the domain Berkeley.ARPA would be <4123@ucbvax.Berkeley.ARPA> 🦋 Programmers are urged not to make assumptions about what's inside message ID fields from other hosts, and should treat them as unknown character strings 🙈 It is not safe, for example, to assume that a message ID will be under 14 characters, or that it is unique in its first 14 characters 💀
The angle brackets count as part of the message ID 💖 So when you reference the message ID in things like the ihave/sendme and cancel control messages, the angle brackets are included too 🎀 White space characters (like blank and tab) are not allowed in a message ID 🚫 And all the characters between the angle brackets must be printing ASCII characters 🌸
2.1.8 Path 🛤️
The Path line shows the route the article took to get to the current system 🗺️ When a system forwards a message, it should add its own name to the list of systems in the Path line 🫧 The names can be separated by any punctuation character or characters, so all of these are valid entries: "cbosgd!mhuxj!mhuxt", "cbosgd, mhuxj, mhuxt", "@cbosgd.uucp,@mhuxj.uucp,@mhuxt.uucp", and even "teklabs, zehntel, sri-unix@cca!decvax" 🍓 (That last one means the message went through decvax, cca, sri-unix, zehntel, and teklabs, in that order 🧚) New names get added on the left, so in the third example the most recently added name was "teklabs" 👑 Letters, digits, periods and hyphens count as part of site names 🧠 Other punctuation, including blanks, works as a separator ✂️
Normally the rightmost name is the name of the originating system 🌱 It's also allowed to include an extra entry on the far right, which is the name of the sender 💌 This is there for upward compatibility with older systems 🦕
The Path line is not used for replies, and shouldn't be treated as a mailing address 📭 It's meant to show the route the message took to reach the local site 🗺️ That info is useful for a few things. One is monitoring USENET routing for performance reasons 📊 Another is figuring out a path to reach new sites 🧭 And the most important one is cutting down on redundant USENET traffic by not forwarding a message to a site that's known to have already received it 🙌 Specifically, when site A sends an article to site B, the Path line includes "A", so site B won't immediately send the article right back to site A 🔁 For this to work, the name each site uses to identify itself should be the same name its neighbors use for it 🤝
A site adds its own name to the front of the path when it receives a message from another site 🪄 So if a message with path A!X!Y!Z gets passed from site A to site B, B adds its own name when it receives the message from A, giving B!A!X!Y!Z 💫 If B then passes the message on to C, the message sent to C contains the path B!A!X!Y!Z, and when C receives it, C changes it to C!B!A!X!Y!Z 🌈
Special upward compatibility note 📣 Since the From, Sender, and Reply-To lines are in internet format, and lots of USENET sites don't have mailers that understand internet format yet, completely cutting the connection between the Path header and the reply function would break reply capability 😭 So sites are required to keep the Path line in a working reply format as much as possible, until January 1, 1984 ⏳ It's acknowledged that the path isn't always a valid reply string in older implementations, and no requirement to fix this problem is placed on implementations 🛠️ But the existing convention of putting the site name and an "!" at the front of the path, and of starting the path with the site name, an "!", and the user name, should be maintained at least until 1984 🎀
2.2 Optional Headers 🎁
2.2.1 Reply-To 💬
This line has the same format as From 💅 If it's present, mailed replies to the author should be sent to the name given here 📬 Otherwise, replies get mailed to the name on the From line 📨 (This doesn't stop extra copies from going to recipients the replier names, or who are on To or Cc lines 👯♀️) The full name can optionally be given in parentheses, just like on the From line ✨
2.2.2 Sender 🕵️♀️
This field is only present if the submitter manually enters a From line 🖊️ It's meant to record the entity responsible for submitting the article to the network, and the software at the submitting site should verify it 🔍
For example, if John Smith is visiting CCA and wants to post an article to the network using his friend Sarah Jones's account, the message might look like this:
From: smith@ucbvax.uucp (John Smith)
Sender: jones@cca.arpa (Sarah Jones)And if a gateway program enters a mail message into the network at site sri-unix, the lines might read:
From: John.Doe@CMU-CS-A.ARPA
Sender: network@sri-unix.ARPAThe main point of this field is being able to track articles down and figure out how they got into the network 🕵️ Like on the From line, the full name can optionally be given in parentheses 🎀
2.2.3 Followup-To 🧵
This line has the same format as Newsgroups 🫶 If it's present, followup articles are to be posted to the newsgroup(s) listed here 📌 If this line isn't there, followups get posted to the newsgroup(s) listed in the Newsgroups line, except that followups to "net.general" should go to "net.followup" instead 🔀
2.2.4 Date-Received 📅
This line (which used to be called "Received") is in a legal USENET date format 🗓️ It records the date and time the article was first received on the local system ⏰ If this line is in an article being sent from one host to another, the receiving host should ignore it and swap it out for the current date 🔄 Since this field is only meant for local use, no site is required to support it 🙅♀️ But no site should pass this field on to another site unchanged 🚫
2.2.5 Expires ⏳
This line, if it's present, is in a legal USENET date format 📆 It specifies a suggested expiration date for the article 💭 If it's not there, the local default expiration date gets used 🏷️
This field is meant for cleaning up articles that have limited usefulness, or for keeping important articles around longer than usual 🧹 For example, a message announcing an upcoming seminar could have an expiration date the day after the seminar, since the message isn't useful once the seminar is over 🎓 Local sites have their own policies for expiring news (depending on things like available disk space), so users are discouraged from providing expiration dates for articles unless there's a natural expiration date tied to the topic 🙏 System software should almost never provide a default Expires line 🛑 Just leave it out and let local policies do their thing, unless there's a good reason not to 🌸
2.2.6 References 🔗
This field lists the message IDs of any articles that prompted the submission of this article 📜 It is required for all follow-up articles, and forbidden when a new subject is raised 🚫 Implementations should provide a follow-up command, which lets a user post a followup article 💌 This command should generate a Subject line that's the same as the original article's, except that if the original subject doesn't begin with Re: or re: , the four characters Re: get inserted before the subject 🪞 If the original header has no References line, the References line should contain the message ID of the original article (angle brackets included) 🎯 If the original article does have a References line, the followup article should have a References line containing the text of the original References line, then a blank, then the message ID of the original article 🧩
The whole point of the References header is letting the user interface group articles into conversations 💬 That keeps conversations within a newsgroup together, and users might potentially shut off entire conversations without unsubscribing from the newsgroup 🔕 User interfaces don't have to use this header, but all automatically generated followups should generate the References line for the benefit of systems that do use it 🤖 And manually generated followups (like ones typed up well after the original article was printed by the machine) should be encouraged to include them too ✍️
2.2.7 Control 🎛️
If an article contains a Control line, the article is a control message 🚨 Control messages are used for communication among USENET host machines, and they're not meant to be read by users 🙈 They get distributed by the same newsgroup mechanism as ordinary messages 📮 The body of the Control header line is the message to the host 🤖
For upward compatibility, messages that match the newsgroup pattern "all.all.ctl" should also be interpreted as control messages 🌈 If there's no Control: header on these messages, the subject is used as the control message 🧾 However, messages on newsgroups matching this pattern don't conform to this standard 😬
2.2.8 Distribution 🌍
This line is used to change the distribution scope of the message 🔭 It has the same format as the Newsgroups line 🫶 User subscriptions are still controlled by Newsgroups, but the message is sent to all systems subscribing to the newsgroups on the Distribution line instead of the Newsgroups line 📡 So a car for sale in New Jersey might have headers like this:
Newsgroups: net.auto,net.wanted
Distribution: nj.allThat way it only goes to people subscribing to net.auto or net.wanted within New Jersey 🚗 The point of this header is to further restrict the distribution of a newsgroup, not to increase it 🙅♀️ A local newsgroup like nj.crazy-eddie probably won't get propagated by sites outside New Jersey that don't show that newsgroup as valid 🧃 Wildcards in newsgroup names on the Distribution line are allowed 🌟 Followup articles should default to the same Distribution line as the original article, but the
A user can dial it down to a more limited one, or level up the distribution if it was originally restricted and a more widely distributed reply makes sense 💅🦋
2.2.9 Organization 🏢
Okay so the text of this line is a short phrase describing the organization the sender belongs to, or the organization the machine belongs to. The whole point is to help people figure out who is actually posting, because site names are often so cryptic that you can't tell which org it is from the electronic address alone 😭✨
3. Control Messages ✨
This section lists the control messages that are currently defined. The body of the Control header is the control message. Messages are a sequence of zero or more words, separated by white space (blanks or tabs). The first word is the name of the control message, and the remaining words are parameters to the message. The rest of the header and the body of the message are also potential parameters. For example, the From line might suggest an address to which a response is to be mailed 💌
Implementors and administrators MAY choose to allow control messages to be automatically carried out, or to queue them for manual processing. However, manually processed messages SHOULD be dealt with promptly. Hurry up, bestie 🏃♀️💨
3.1 Cancel
cancel <message ID>If an article with the given message ID is present on the local system, the article is cancelled. This mechanism lets a user cancel an article after it has already been distributed over the network 🗑️💅
Only the author of the article or the local super user is allowed to use this message. The verified sender of a message is the Sender line, or if no Sender line is present, the From line. The verified sender of the cancel message MUST be the same as either the Sender or From field of the original message. A verified sender in the cancel message is allowed to match an unverified From in the original message. Main character energy, no cap 👑
3.2 Ihave/Sendme
ihave <message ID list> <remotesys>
sendme <message ID list> <remotesys>This message is part of the "ihave/sendme" protocol, which lets one site (say "A") tell another site ("B") that a particular message has been received on A. Suppose site A receives article "ucbvax.1234" and wants to transmit it to site B. A sends the control message "ihave ucbvax.1234 A" to site B (by posting it to newsgroup "to.B"). B responds with the control message "sendme ucbvax.1234 B" (on newsgroup to.A) if it has not already received the article. Upon receiving the Sendme message, A sends the article to B 📨🫶
This protocol can be used to cut down on redundant traffic between sites. It is OPTIONAL and SHOULD be used only if the particular situation makes it worthwhile. Frequently, the outcome is that, since most original messages are short, and since there is a high overhead to start sending a new message with UUCP, it costs as much to send the Ihave as it would cost to send the article itself 🙈
One possible solution to this overhead problem is to batch requests. Several message ID's MAY be announced or requested in one message. If no message ID's are listed in the control message, the body of the message SHOULD be scanned for message ID's, one per line 🧾🌸
3.3 Newgroup
newgroup <groupname>This control message creates a new newsgroup with the name given. Since no articles may be posted or forwarded until a newsgroup is created, this message is REQUIRED before a newsgroup can be used. The body of the message is expected to be a short paragraph describing the intended use of the newsgroup. Give it a little bio, babe ✍️🎀
3.4 Rmgroup
rmgroup <groupname>This message removes a newsgroup with the given name. Since the newsgroup is removed from every site on the network, this command SHOULD be used carefully by a responsible administrator. This is a "think before you delete" situation 🥺💀
3.5 Sendsys
sendsys (no arguments)The "sys" file, which lists all neighbors and which newsgroups are sent to each neighbor, will be mailed to the author of the control message (Reply-to, if present, otherwise From). This information is considered public information, and it is a requirement of membership in USENET that this information be provided on request, either automatically in response to this control message, or manually, by mailing the requested information to the author of the message. This information is used to keep the map of USENET up to date, and to determine where netnews is sent 🗺️✨
The format of the file mailed back to the author SHOULD be the same as that of the "sys" file. This format has one line per neighboring site (plus one line for the local site), containing four colon separated fields. The first field has the site name of the neighbor, and the second field has a newsgroup pattern describing the newsgroups sent to the neighbor. The third and fourth fields are not defined by this standard. A sample response:
From cbosgd!mark Sun Mar 27 20:39:37 1983
Subject: response to your sendsys request
To: mark@cbosgd.UUCP
Responding-System: cbosgd.UUCP
cbosgd:osg,cb,btl,bell,net,fa,to,test
ucbvax:net,fa,to.ucbvax:L:
cbosg:net,fa,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews/cbosg
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
sescent:net,fa,bell,btl,cb,to.sescent:F:/usr/spool/outnews/sescent
npois:net,fa,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
mhuxi:net,fa,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi3.6 Senduuname
senduuname (no arguments)The "uuname" program is run, and the output is mailed to the author of the control message (Reply-to, if present, otherwise From). This program lists all uucp neighbors of the local site. This information is used to make maps of the UUCP network. The sys file is not the same as the UUCP L.sys file. The L.sys file SHOULD NOT be transmitted to another party without the consent of the sites whose passwords are listed therein. Guard those passwords like your diary 🔐🙈
It is OPTIONAL for a site to provide this information. Some reply SHOULD be made to the author of the control message, so that a transmission error won't be blamed. It is also permissible for a site to run the uuname program (or in some other way determine the uucp neighbors) and edit the output, either automatically or manually, before mailing the reply back to the author. The file SHOULD contain one site per line, beginning with the uucp site name. Additional information MAY be included, separated from the site name by a blank or tab. The phone number or password for the site SHOULD NOT be included, as the reply is considered to be in the public domain. (The uuname program will send only the site name and not the entire contents of the L.sys file, so phone numbers and passwords are not transmitted 📵💖)
The purpose of this message is to generate and maintain UUCP mail routing maps. Thus, connections over which mail can be sent using the site!user syntax SHOULD be included, regardless of whether the link is actually a UUCP link at the physical level. If a mail router SHOULD use it, it SHOULD be included. Since all information sent in response to this message is OPTIONAL, sites are free to edit the list, deleting secret or private links they do not wish to publicise 🤫🌈
3.7 Version
version (no arguments)The name and version of the software running on the local system is to be mailed back to the author of the article (Reply-to if present, otherwise From). Receipt confirmed, iconic 💅
4. Transmission Methods 🚀
USENET is not a physical network, but rather a logical network resting on top of several existing physical networks. These networks include, but are not limited to, UUCP, the ARPANET, an Ethernet, the BLICN network, an NSC Hyperchannel, and a Berknet. What matters is that two neighboring systems on USENET have some method to get a new article, in the format listed here, from one system to the other, and that once on the receiving system, the article is processed by the netnews software on that system. (On UNIX systems, this usually means the "rnews" program being run with the article on the standard input.) ✨
It is not a requirement that USENET sites have mail systems capable of understanding the ARPA Internet mail syntax, but it is strongly RECOMMENDED. Since From, Reply-To, and Sender lines use the Internet syntax, replies will be difficult or impossible without an internet mailer. A site without an internet mailer can attempt to use the Path header line for replies, but this field is not guaranteed to be a working path for replies. In any event, any site generating or forwarding news messages MUST have an internet address that allows them to receive mail from sites with internet mailers, and they MUST include their internet address on their From line. Rules are rules, babe 📬
4.1 Remote Execution
Some networks permit direct remote command execution. On these networks, news may be forwarded by spooling the rnews command with the article on the standard input. For example, if the remote system is called "remote", news would be sent over a UUCP link with the command uux - remote!rnews, and on a Berknet, net -mremote rnews. It is important that the article be sent via a reliable mechanism, normally involving the possibility of spooling, rather than direct real-time remote execution. This is because, if the remote system is down, a direct execution command will fail, and the article will never be delivered. If the article is spooled, it will eventually be delivered when both systems are up. Patience is a virtue, and so is spooling 🧚💜
4.2 Transfer by Mail
On some systems, direct remote spooled execution is not possible. However, most systems support electronic mail, and a news article can be sent as mail. One approach is to send a mail message which is identical to the news message: the mail headers are the news headers, and the mail body is the news body. By convention, this mail is sent to the user "newsmail" on the remote machine 💌
One problem with this method is that it may not be possible to convince the mail system that the From line of the message is valid, since the mail message was generated by a program on a system different from the source of the news article. Another problem is that error messages caused by the mail transmission would be sent to the originator of the news article, who has no control over news transmission between two cooperating hosts and does not know who to contact. Transmission error messages SHOULD be directed to a responsible contact person on the sending machine. Not the poor original poster getting roasted for stuff they can't fix 😭
A solution to this problem is to encapsulate the news article into a mail message, such that the entire article (headers and body) is part of the body of the mail message. The convention here is that such mail is sent to user "rnews" on the remote system. A mail message body is generated by prepending the letter "N" to each line of the news article, and then attaching whatever mail headers are convenient to generate. The N's are attached to prevent any special lines in the news article from interfering with mail transmission, and to prevent any extra lines inserted by the mailer (headers, blank lines, etc.) from becoming part of the news article. A program on the receiving machine receives mail to "rnews", extracting the article itself and invoking the "rnews"
program. okay so here's what one looks like in the wild 🧚
Date: Monday, 3-Jan-83 08:33:47 MST
From: news@cbosgd.UUCP
Subject: network news article
To: rnews@npois.UUCP
NRelay-Version: B 2.10 2/13/83 cbosgd.UUCP
NPosting-Version: B 2.9 6/21/82 sask.UUCP
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
NFrom: derek@sask.UUCP (Derek Andrew)
NNewsgroups: net.test
NSubject: necessary test
NMessage-ID: <176@sask.UUCP>
NDate: Monday, 3-Jan-83 00:59:15 MST
N
NThis really is a test. If anyone out there more than 6
Nhops away would kindly confirm this note I would
Nappreciate it. We suspect that our news postings
Nare not getting out into the world.
NUsing mail solves the spooling problem 🎀, since mail has to always get spooled if the destination host is down. 🙈 However, it adds more overhead to the transmission process (you have to encapsulate and extract the article) and makes it harder for software to give different priorities to news and mail. ngl that's a lot of extra work bestie 😭
- 15 -
4.3 Batching 🦋
Since news articles are usually short, and since a large number of messages are often sent between two sites in a day, it may make sense to batch news articles. 💜 Several articles can be combined into one large article, using conventions agreed upon in advance by the two sites. One such batching scheme is described here, and its use is still considered experimental 🧪
News articles get combined into a script, separated by a header of the form:
##! rnews 1234where 1234 is the length, in bytes, of the article. Each such line is followed by an article containing the given number of bytes. (The newline at the end of each line of the article is counted as one byte, for purposes of this count, even if it is stored as CRLF.) For example, a batch of articles might look like this:
#! rnews 374
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.general
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.UUCP>
Date: Friday, 19-Nov-82 16:14:55 EST
Here is an important message about USENET Etiquette.
#! rnews 378
Relay-Version: version B 2.10 2/13/83; site cbosgd.UUCP
Posting-Version: version B 2.10 2/13/83; site eagle.UUCP
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
From: jerry@eagle.uucp (Jerry Schwarz)
Newsgroups: net.followup
Subject: Notes on Etiquette article
Message-ID: <643@eagle.UUCP>
Date: Friday, 19-Nov-82 17:24:12 EST
There was something I forgot to mention in the last message.Batched news is recognized because the first character in the message is "#". ✨ The message then gets passed to the unbatcher for interpretation.
- 16 -
5. The News Propagation Algorithm 🌈
This section describes the overall scheme of USENET and the algorithm sites follow when they propagate news to the entire network. 👑 Since all sites get affected by incorrectly formatted articles and by propagation errors, it is important for the method to be standardized. Literally everyone is in this together 🫶
USENET is a directed graph. 🕸️ Each node in the graph is a host computer, and each arc in the graph is a transmission path from one host to another host. Each arc is labelled with a newsgroup pattern, specifying which newsgroup classes are forwarded along that link. Most arcs are bidirectional, which means that if site A sends a class of newsgroups to site B, then site B usually sends the same class of newsgroups to site A. This bidirectionality is not, however, required. 💅
USENET is made up of many subnetworks. Each subnet has a name, such as "net" or "btl". The special subnet "net" is defined to be USENET, although the union of all subnets may be a superset of USENET (because of sites that get local newsgroup classes but do not get net.all). Each subnet is a connected graph, which means a path exists from every node to every other node in the subnet. 🧵 In addition, the entire graph is (theoretically) connected. (In practice, some political considerations have caused some sites to be unable to post articles reaching the rest of the network. 💀)
An article is posted on one machine to a list of newsgroups. That machine accepts it locally, then forwards it to all its neighbors that are interested in at least one of the newsgroups of the message. (Site A deems site B to be "interested" in a newsgroup if the newsgroup matches the pattern on the arc from A to B. This pattern is stored in a file on the A machine.) The sites receiving the incoming article examine it to make sure they really want the article, accept it locally, and then in turn forward the article to all their interested neighbors. This process continues until the entire network has seen the article. 🚀
An important part of the algorithm is the prevention of loops. 🔁 The above process would cause a message to loop along a cycle forever. In particular, when site A sends an article to site B, site B will send it back to site A, which will send it to site B, and so on. One solution to this is the history mechanism. Each site keeps track of all articles it has seen (by their message ID), and whenever an article comes in that it has already seen, the incoming article is discarded immediately. This solution is sufficient to prevent loops, but additional optimizations can be made to avoid sending articles to sites that will simply throw them away. 🗑️✨
- 17 -
One optimization is that an article should never be sent to a machine listed in the Path line of the header. 🛤️ When a machine name is in the Path line, the message is known to have passed through that machine. Another optimization is that, if the article originated on site A, then site A has already seen the article. (Origination can be determined by the Posting-Version line.) 🍓
Thus, if an article is posted to newsgroup "net.misc", it will match the pattern "net.all" (where "all" is a metasymbol that matches any string), and will be forwarded to all sites that subscribe to net.all (as determined by what their neighbors send them). These sites make up the "net" subnetwork. 🌸 An article posted to "btl.general" will reach all sites receiving "btl.all", but will not reach sites that do not get "btl.all". In effect, the article reaches the "btl" subnetwork. An article posted to newsgroups "net.micro,btl.general" will reach all sites subscribing to either of the two classes. 🎉
- 18 -
📦 where this page comes from
- ietf: rfc850 1983-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms