RFC 1036
Standard for interchange of USENET messages
1. Introduction ✨
Okay so this doc sets the standard format for swapping network News messages between USENET hosts 💖. It covers the format of the messages themselves and gives partial standards for how news gets transmitted. Transmission is deliberately not fully locked down, so hosts get lots of freedom to pick their own hardware and software, batch news, and so on 🧚.
There are five sections in this doc 🎀. Section two is the format. Section three is the valid control messages. Section four spells out some valid transmission methods. Section five describes the overall news propagation algorithm 👑.
2. Message Format 📮
The big priority when picking a message format is to fit in with existing tools as well as possible 🛠️. Existing tools include implementations of both mail and news. (The notesfiles system from the University of Illinois counts as a news implementation.) A standard format for mail messages has existed on the Internet for years, and it meets most of USENET's needs. The Internet format is extensible, so extensions for USENET's extra needs can be made inside the Internet standard 🌈.
So the rule is that all USENET news messages MUST be formatted as valid Internet mail messages, according to the Internet standard RFC-822 💌. The USENET News standard is stricter than the Internet standard. It adds requirements to each message and forbids certain Internet features. Still, it SHOULD always be possible to use a tool that expects an Internet message to process a news message 🫶. If this standard ever conflicts with the Internet standard, RFC-822 SHOULD be considered correct and this standard in error 💅.
Here's an example USENET message so you can see the fields 👀.
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.ATT.COM>
Date: Fri, 19 Nov 82 16:14:55 GMT
Followup-To: news.misc
Expires: Sat, 1 Jan 83 00:00:00 -0500
Organization: AT&T Bell Laboratories, Murray Hill
The body of the message comes here, after a blank line.Here's an example of a message in the old format (from before this standard existed) 🕰️. It is RECOMMENDED that implementations also accept messages in this format to ease upward conversion 🌸.
From: cbosgd!mhuxj!mhuxt!eagle!jerry (Jerry Schwarz)
Newsgroups: news.misc
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 message comes here, after a blank line.Some news systems transmit news in the A format, which looks like this 🧾.
Aeagle.642
news.misc
cbosgd!mhuxj!mhuxt!eagle!jerry
Fri Nov 19 16:14:55 1982
Usenet Etiquette - Please Read
The body of the message comes here, with no blank line.A standard USENET message is a bunch of 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. It's a subset of the Internet standard, simplified so simpler software can handle it 🧸. The From line MAY optionally include a full name, in the format above, or use the Internet angle bracket syntax. To keep implementations simple, other formats (like part of the machine address after the close parenthesis) are not allowed 🚫. The Internet convention of continuation header lines (starting with a blank or tab) is allowed ✨.
Certain headers are REQUIRED, and certain other headers are OPTIONAL 📋. Any unrecognized headers are allowed, and they get passed through unchanged 🦋. The REQUIRED header lines are From, Date, Newsgroups, Subject, Message-ID, and Path. The OPTIONAL header lines are Followup-To, Expires, Reply-To, Sender, References, Control, Distribution, Keywords, Summary, Approved, Lines, Xref, and Organization. We'll go through each of these header lines below 🌷.
2.1. Required Header lines 📋
2.1.1. From 💌
The From line has the electronic mailing address of the person who sent the message, in Internet syntax 📬. It MAY optionally also contain the person's full name in parentheses, right after the electronic address. The electronic address is the same as the entity responsible for originating the message, unless a Sender header is present. In that case the From header might not be verified 👀.
Quick tea ☕: in all host and domain names, upper and lower case count as the same. So mark@cbosgd.ATT.COM, mark@cbosgd.att.com, and mark@CBosgD.ATt.COm are all equivalent 🫠. User names might be case sensitive, though. For example, Billy@cbosgd.ATT.COM might be different from BillY@cbosgd.ATT.COM 🤯. Programs SHOULD avoid changing the case of electronic addresses when forwarding news or mail 🫶.
RFC-822 says all text in parentheses is a comment. It's really common in Internet mail to put the user's full name in a comment at the end of the From line 💅. This standard is more rigid than that. The full name is not treated as a comment. It's an OPTIONAL part of the header line instead. Either the full name is left out, or it shows up in parentheses after the electronic address of the person posting, or it shows up before an electronic address enclosed in angle brackets 🎀. So the three allowed forms are:
From: mark@cbosgd.ATT.COM
From: mark@cbosgd.ATT.COM (Mark Horton)
From: Mark Horton <mark@cbosgd.ATT.COM>Full names MAY contain any printing ASCII characters from space through tilde, except that they may not contain ( (left parenthesis), ) (right parenthesis), < (left angle bracket), or > (right angle bracket) 🚧. Additional restrictions MAY be placed on full names by the mail standard. In particular, the characters , (comma), : (colon), @ (at), ! (bang), / (slash), = (equal), and ; (semicolon) are inadvisable in full names 😬.
2.1.2. Date 🗓️
The Date line (formerly Posted) is the date the message was originally posted to the network ⏰. Its format MUST be acceptable both in RFC-822 and to the getdate(3) routine that comes with the Usenet software 🧠. This date stays the same as the message travels around the network 🔒. One format that works for both is:
Wdy, DD Mon YY HH:MM:SS TIMEZONEThere are several examples of valid dates in the sample message above 📅. Heads up about ctime(3) format, though 👻:
Wdy Mon DD HH:MM:SS YYYYThat one is not acceptable, because it isn't a valid RFC-822 date 🙅. BUT older software still spits this format out, so news implementations are encouraged to accept it and translate it into an acceptable format 🔄.
There's no hope of ever having a complete list of timezones 🌍. Universal Time (GMT), the North American timezones (PST, PDT, MST, MDT, CST, CDT, EST, EDT), and the +/-hhmm offset specified in RFC-822 SHOULD be supported. It is RECOMMENDED that times in message headers be transmitted in GMT and displayed in the local time zone 🕐✨.
2.1.3. Newsgroups 📰
The Newsgroups line says which newsgroup or newsgroups the message belongs in 💬. You can list several, separated by a comma. Newsgroups MAY be specified in a bunch like that, but they MUST all be names of existing newsgroups, since posting to a group doesn't create it 🚫🆕.
Wildcards (like the word "all") are never allowed in a Newsgroups line 🙅♀️. For example, the newsgroup comp.all is illegal, but rec.sport.football is totally permitted 🏈.
If a message comes in with a Newsgroups line listing some valid newsgroups and some invalid ones, a host SHOULD NOT remove the invalid newsgroups from the list 🧐. Instead, the invalid newsgroups SHOULD be ignored. Here's the example. Say host A subscribes to the classes btl.all and comp.all, and it swaps news messages with host B. Host B subscribes to comp.all but not btl.all. Now suppose A gets a message with Newsgroups: comp.unix,btl.general 🍿.
That message gets passed on to B, because B receives comp.unix, even though B doesn't receive btl.general 📨. A MUST leave the Newsgroups line unchanged. Why? If A removed btl.general, the edited header could eventually sneak back into the btl.all class. Then you'd get a message that never shows up for people subscribed to btl.general 😭. Follow-ups from outside btl.all wouldn't show up for those folks either 💔.
2.1.4. Subject 🎀
The Subject line (formerly Title) says what the message is about 🏷️. It SHOULD be suggestive enough of the message's contents that a reader can decide whether to read it based on the subject alone 👑. If the message is a response to another message (like a follow-up), the default subject SHOULD begin with the four characters Re:, and the References line is REQUIRED 💅. For follow-ups, using the Summary line is encouraged 💖.
2.1.5. Message-ID 🆔
okay so the "Message-ID" line is basically the message's own unique name tag 🏷️💖 every message gets one, and the Message-ID may not be reused during the lifetime of any previous message with the same Message-ID. (it is recommended that no Message-ID be reused for at least two years 📅✨) the syntax is literally just:
<string not containing blank or ">">bestie, listen 👂 in order to conform to RFC-822, the Message-ID must have this exact format:
<unique@full_domain_name>where full_domain_name is the full name of the host where the message entered the network, including a domain that host is in, and unique is any string of printing ASCII characters, not including < (left angle bracket), > (right angle bracket), or @ (at sign). it's giving very specific but also very iconic 💅
the unique part could be an integer representing a sequence number for messages submitted to the network, or a short string derived from the date and time the message was created. for example, a valid Message-ID for a message submitted from host ucbvax in domain "Berkeley.EDU" would be <4123@ucbvax.Berkeley.EDU> 🎀
programmers are urged not to make assumptions about the content of Message-ID fields from other hosts, and should instead treat them as unknown character strings 🙈 it is not safe, for example, to assume that a Message-ID will be under 14 characters, that it is unique in the first 14 characters, nor that it does not contain a /. not me assuming things 💀
the angle brackets are considered part of the Message-ID 🦋 so when you reference it (like in the ihave/sendme and cancel control messages), the angle brackets are included too. white space characters (e.g., blank and tab) are not allowed in a Message-ID. slashes (/) are strongly discouraged 🙅♀️ and all characters between the angle brackets must be printing ASCII characters. periodt 💜
2.1.6. Path 🛤️
okay this line shows the path the message took to reach the current system 🗺️✨ when a system forwards the message, it should add its own name to the list of systems in the "Path" line. the names may be separated by any punctuation character or characters (except ., which is considered part of the hostname). so these are all valid entries:
cbosgd!mhuxj!mhuxt
cbosgd, mhuxj, mhuxt
@cbosgd.ATT.COM,@mhuxj.ATT.COM,@mhuxt.ATT.COM
teklabs, zehntel, sri-unix@cca!decvax(the latter path indicates a message that passed through decvax, cca, sri-unix, zehntel, and teklabs, in that order.) additional names should be added from the left 👈 so the most recently added name in the fourth example was teklabs. letters, digits, periods and hyphens are considered part of host names 🌸 other punctuation, including blanks, are considered separators.
normally, the rightmost name will be the name of the originating system. however, it is also permissible to include an extra entry on the right, which is the name of the sender. this is for upward compatibility with older systems 🧚
the "Path" line is not used for replies, and should not be taken as a mailing address. it is intended to show the route the message traveled to reach the local host. there are several uses for this info: one is to monitor USENET routing for performance reasons, another is to establish a path to reach new hosts, and perhaps the most important use is to cut down on redundant USENET traffic by failing to forward a message to a host that is known to have already received it. 🔥
in particular, when host A sends a message to host B, the "Path" line includes A, so that host B will not immediately send the message back to host A 🔁 the name each host uses to identify itself should be the same as the name by which its neighbors know it, in order to make this optimization possible. no cap, that's the whole vibe ✨
a host adds its own name to the front of a path when it receives a message from another host. so if a message with path A!X!Y!Z is passed from host A to host B, B will add its own name to the path when it receives the message from A, e.g., B!A!X!Y!Z. if B then passes the message on to C, the message sent to C will contain the path B!A!X!Y!Z, and when C receives it, C will change 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 since many USENET hosts do not yet have mailers capable of understanding Internet format, it would break the reply capability to completely sever the connection between the "Path" header and the reply function. it is recognized that the path is not always a valid reply string in older implementations, and no requirement to fix this problem is placed on implementations. however, the existing convention of placing the host name and an ! at the front of the path, and of starting the path with the host name, an !, and the user name, should be maintained when possible 🌈
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 are mailed to the name on the "From" line. (this does not prevent additional copies from being sent to recipients named by the replier, or on "To" or "Cc" lines.) the full name may be optionally given, in parentheses, as in the "From" line 💅
2.2.2. Sender 🕵️♀️
this field is present only if the submitter manually enters a "From" line 👀 it's intended to record the entity responsible for submitting the message to the network, and it should be verified by the software at the submitting host.
for example, if John Smith is visiting CCA and wishes to post a message to the network using friend Sarah Jones' account, the message might read:
From: smith@ucbvax.Berkeley.EDU (John Smith)
Sender: jones@cca.COM (Sarah Jones)if a gateway program enters a mail message into the network at host unix.SRI.COM, the lines might read:
From: John.Doe@A.CS.CMU.EDU
Sender: network@unix.SRI.COMthe primary purpose of this field is to be able to track down messages and figure out how they were entered into the network 🔍 the full name may be optionally given, in parentheses, as in the "From" line.
2.2.3. Followup-To 💬
this line has the same format as "Newsgroups". if it's present, follow-up messages are to be posted to the newsgroup or newsgroups listed here. if this line is not present, follow-ups are posted to the newsgroup or newsgroups listed in the "Newsgroups" line 🌸
if the keyword poster is present, follow-up messages are not permitted. the message should be mailed to the submitter of the message via mail 📬
2.2.4. Expires ⏳
this line, if present, is in a legal USENET date format. it specifies a suggested expiration date for the message. if it's not present, the local default expiration date is used. this field is meant for cleaning up messages with limited usefulness, or for keeping important messages 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 🎓
since local hosts have local policies for expiration of news (depending on available disk space, for instance), users are discouraged from providing expiration dates for messages unless there is a natural expiration date associated with the topic 🙅♀️ system software should almost never provide a default "Expires" line. leave it out and let local policies do their thing unless there's a good reason not to. 🫶
2.2.5. References 🧵
this field lists the Message-ID's of any messages prompting the submission of this message. it is required for all follow-up messages, and forbidden when a new subject is raised 🚫 implementations should provide a follow-up command that lets a user post a follow-up message. this command should generate a "Subject" line that's the same as the original message, except that if the original subject does not begin with Re: or re:, the four characters Re: are inserted before the subject 💖
if there's no "References" line on the original header, the "References" line should contain the Message-ID of the original message (including the angle brackets). if the original message does have a "References" line, the follow-up message should have a "References" line containing the text of the original "References" line, a blank, and the Message-ID of the original message 🦋
the purpose of the "References" header is to let the user interface group messages into conversations. this keeps conversations within a newsgroup together, and potentially lets users shut off entire conversations without unsubscribing from a newsgroup 🌈 user interfaces don't need to use this header, but all automatically generated follow-ups should generate the "References" line for the benefit of systems that do use it. manually generated follow-ups (e.g., typed in well after the original message has been printed by the machine) should be encouraged to include them as well 🧚
it is permissible to not include the entire previous "References" line if it is too long. an attempt should be made to include a reasonable number of backwards references 🔗
2.2.6. Control 🤖
if a message contains a "Control" line, the message 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're 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 no "Control" header is present on such messages, the subject is used as the control message. however, messages on newsgroups matching this pattern do not conform to this standard 💀
also for upward compatibility, if the first 4 characters of the Subject: line are cmsg, the rest of the Subject: line should be interpreted as a control message 🍓
2.2.7. Distribution 🌍
okay bestie, this line changes who gets the message 🌍 it's a comma separated list, just like Newsgroups. your subscriptions are still decided by Newsgroups, but the message also goes to every system subscribed to the groups on the Distribution line, on top of the Newsgroups ones ✨ for it to actually get transmitted, the receiving site normally has to receive one of the specified newsgroups AND one of the specified distributions. so a message about a car for sale in New Jersey might have these headers:
Newsgroups: rec.auto,misc.forsale
Distribution: nj,nyand it would only go to people subscribed to rec.auto or misc.forsale within New Jersey or New York 🚗 the whole point of this header is to restrict a newsgroup further, not to increase it 🙅♀️ a local newsgroup like nj.crazy-eddie will probably not get propagated by hosts outside New Jersey that do not show it as valid, which is so fair honestly 💅
a follow-up should default to the same Distribution line as the original, but the user can make it more limited, or escalate it if the original was restricted and a more widely distributed reply is appropriate 🦋
2.2.8. Organization 🏢
the text here is a short phrase describing the organization the sender belongs to, or the organization the machine belongs to 🏢 the whole reason this line exists is to help identify the person posting, since host names can be so cryptic that it's hard to tell the organization from the email-style address 🙈
2.2.9. Keywords 🏷️
a few well-picked keywords that identify the message should go on this line 🏷️ it's basically a little aid for the reader, helping them decide if the message is interesting to them 👀
2.2.10. Summary 📝
this line should have a brief summary of the message 📝 it's usually used in a follow-up to another message, and it's super useful for the reader deciding whether to read the thing at all 💖
2.2.11. Approved ✅
this line is required for any message posted to a moderated newsgroup 🛡️ the moderator should add it, and it should consist of their mail address. it's also required with certain control messages 💜
2.2.12. Lines 🔢
this line contains a count of how many lines are in the body of the message 🔢 simple but iconic 💅
2.2.13. Xref 🗂️
this line contains the name of the host (with domains left off) and a white space separated list of colon-separated pairs. each pair is a newsgroup name and a message number, so it's basically the groups from the Newsgroups line matched up with their message numbers in the spool directory 🗂️
this is only of value to the local system, so it should not be transmitted 🚫 here's an example:
Path: seismo!lll-crg!lll-lcc!pyramid!decwrl!reid
From: reid@decwrl.DEC.COM (Brian Reid)
Newsgroups: news.lists,news.groups
Subject: USENET READERSHIP SUMMARY REPORT FOR SEP 86
Message-ID: <5658@decwrl.DEC.COM>
Date: 1 Oct 86 11:26:15 GMT
Organization: DEC Western Research Laboratory
Lines: 441
Approved: reid@decwrl.UUCP
Xref: seismo news.lists:461 news.groups:6378so the Xref line here says the message is number 461 in news.lists and number 6378 in news.groups, on the host seismo 🧚 some user interfaces can use this info, and that's the vibe 🌸
3. Control Messages 🎛️
okay so this section is the list of 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 its parameters. the rest of the header and the body of the message can also count as parameters too. like, the From line might suggest an address to send a response to, which is giving main character energy 🎀
implementors and administrators can choose to let control messages run automatically, or to queue them for annual processing 🗓️ but manually processed messages should be dealt with promptly, bestie ⏰
failed control messages should NOT be mailed to the originator of the message. they go to the local "usenet" account instead 📬
3.1. Cancel 🗑️
cancel <Message-ID>if a message with the given Message-ID is on the local system, that message gets cancelled 🗑️ this is how a user can cancel a message even after it's already been distributed over the network, which is iconic 🙌
if the system can't cancel the message as requested, it should not forward the cancellation request to its neighbor systems 🚫
only the author of the message or the local news administrator is allowed to send this 🔐 the verified sender of a message is the Sender line or, if there isn't a Sender line, 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. and a verified sender in the cancel message is allowed to match an unverified From in the original message 🧐
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 host (say A) tell another host (B) that a particular message has been received on A 🤝 imagine host A gets the message <1234@ucbvax.Berkeley.edu> and wants to send it to host B 💌
so A sends the control message ihave <1234@ucbvax.Berkeley.edu> A to host B (by posting it to the newsgroup to.B). then B responds with the control message sendme <1234@ucbvax.Berkeley.edu> B (on the newsgroup to.A), but only if it has not already received the message. once A gets that sendme, A sends the message to B 🚀
this protocol can help cut down on redundant traffic between hosts. it is optional and should be used only if the situation makes it worth it 🤔 honestly, most original messages are short, and there's a high overhead to start sending a new message with UUCP, so it can cost as much to send the ihave as it would to just send the message itself 😭
one possible fix for this overhead is to batch requests 📦 several Message-IDs can be announced or requested in one message. if no Message-IDs are listed in the control message, the body of the message should be scanned for Message-IDs, one per line 🔍
3.3. Newgroup 🌱
newgroup <groupname> [moderated]this control message creates a brand new newsgroup with the given name 🌱 nothing can be posted or forwarded until a newsgroup exists, so this message is required before a newsgroup can be used 💅 the body is expected to be a short paragraph describing what the newsgroup is for 📖
if the second argument is present and it's the keyword moderated, the group should be created moderated instead of the default, which is unmoderated 🛡️ the newgroup message should be ignored unless there is an Approved line in the same message header 👀
3.4. Rmgroup 💥
rmgroup <groupname>this message removes a newsgroup with the given name 💥 since the newsgroup gets removed from every host on the network, this command should be used carefully by a responsible administrator 🫶 the rmgroup message should be ignored unless there is an Approved: line in the same message header ✅
3.5. Sendsys 🗺️
sendsys (no arguments)the sys file, listing all neighbors and the newsgroups to be sent to each neighbor, will be mailed to the author of the control message (Reply-To, if present, otherwise From) 📨 this info is considered public, and being a member of USENET means you have to provide it on request. that can happen automatically in response to this control message, or manually, by mailing the requested info to the author of the message 🫡 it's used to keep the map of USENET up to date and to figure out where netnews gets sent 🗺️✨
the format of the file mailed back should be the same as the sys file's format. it has one line per neighboring host (plus one line for the local host), with four colon separated fields. the first field is the host name of the neighbor, and the second field is a newsgroup pattern describing the newsgroups sent to that neighbor. the third and fourth fields are not defined by this standard 🤷♀️ and just so you know, the sys file is not the same as the UUCP L.sys file 🙈 here's a sample response:
From: cbosgd!mark (Mark Horton)
Date: Sun, 27 Mar 83 20:39:37 -0500
Subject: response to your sendsys request
To: mark@cbosgd.ATT.COM
Responding-System: cbosgd.ATT.COM
cbosgd:osg,cb,btl,bell,world,comp,sci,rec,talk,misc,news,soc,to,
test
ucbvax:world,comp,to.ucbvax:L:
cbosg:world,comp,bell,btl,cb,osg,to.cbosg:F:/usr/spool/outnews
/cbosg
cbosgb:osg,to.cbosgb:F:/usr/spool/outnews/cbosgb
sescent:world,comp,bell,btl,cb,to.sescent:F:/usr/spool/outnews
/sescent
npois:world,comp,bell,btl,ug,to.npois:F:/usr/spool/outnews/npois
mhuxi:world,comp,bell,btl,ug,to.mhuxi:F:/usr/spool/outnews/mhuxi3.6. 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 message (Reply-to if present, otherwise From) 📬 simple, clean, very on brand 💖
3.7. Checkgroups 🔎
the message body is a list of "official" newsgroups and their descriptions, one group per line 📋 those get compared against the list of active newsgroups on the current host. the names of any obsolete or new newsgroups are mailed to the user "usenet", and the descriptions of the new newsgroups get added to the help file used when posting news 📝
4. Transmission Methods 🚚
okay so USENET isn't a physical network at all 🌐 it's a logical network sitting on top of several existing physical networks. those include, but aren't limited to, UUCP, the Internet, an Ethernet, the BLICN network, an NSC Hyperchannel, and a BERKNET 🔌 what really matters is that two neighboring systems on USENET have some way to get a new message, in the format listed here, from one system to the other. then, once it's on the receiving system, the netnews software there has to process it 🚚 (on UNIX systems, this usually means the rnews program is run with the message on the standard input. <1>) 🧠
it isn't required that USENET hosts have mail systems that understand Internet mail syntax, but it is strongly recommended 💌 the From, Reply-To, and Sender lines use Internet syntax, so without an Internet mailer, replies will be difficult or impossible 😩 a host without an Internet mailer can try using the Path header line for replies, but that field is not guaranteed to be a working path for replies 🫠 either way, any host that generates or forwards news messages must have an Internet address that lets it receive mail from hosts with Internet mailers, and they must include that Internet address on their From line 🦋✨
4.1. Remote Execution 🚀
okay so some networks let you run commands directly on another machine, and on those networks news can get forwarded by spooling the rnews command with the message fed into standard input 🤯. For example, if the remote system is called remote, news would get sent over a UUCP link with this command:
uux - remote!rnewsand on a Berknet it'd be:
net -mremote rnewsIt's really important the message goes through a reliable mechanism, normally one that involves spooling, instead of direct real-time remote execution 💅. Why? If the remote system is down, a direct execution command just fails and the message is never delivered 💀. But if it's spooled, it'll eventually get delivered once both systems are up 🙌.
4.2. Transfer by Mail 📬
On some systems, direct remote spooled execution isn't possible 😤. But most systems support email, so a news message can be sent as mail ✨. One approach is to send a mail message that's identical to the news message: the mail headers are the news headers, and the mail body is the news body. By convention, this mail goes to the user newsmail on the remote machine.
Here's the catch. It may not be possible to convince the mail system that the "From" line is valid, since the mail was generated by a program on a different system from where the news came from 🙃. Another problem is that error messages caused by the mail transmission would get sent back to the originator of the news message, who has zero control over news transmission between the two cooperating hosts and has no idea who to contact 😭. So transmission error messages should be directed to a responsible contact person on the sending machine.
The fix is to encapsulate the news message inside a mail message, so the entire message (headers and body) becomes part of the mail body 🫶. The convention here is that this mail goes to the user rnews on the remote system. The mail body is made by prepending the letter N to each line of the news message, then attaching whatever mail headers are convenient. The N's are there so special lines in the news message can't mess with mail transmission, and so extra lines added by the mailer (headers, blank lines, etc.) can't sneak into the news message 🧠. A program on the receiving machine gets the mail to rnews, pulls out the message, and invokes the rnews program. Here's what an example in this format might look like:
Date: Mon, 3 Jan 83 08:33:47 MST
From: news@cbosgd.ATT.COM
Subject: network news message
To: rnews@npois.ATT.COM
NPath: cbosgd!mhuxj!harpo!utah-cs!sask!derek
NFrom: derek@sask.UUCP (Derek Andrew)
NNewsgroups: misc.test
NSubject: necessary test
NMessage-ID: <176@sask.UUCP>
NDate: Mon, 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 must always be spooled if the destination host is down 🧚. However, it adds more overhead to the transmission process (to encapsulate and extract the message), and it makes it harder for software to give different priorities to news and mail 🥲.
4.3. Batching 📦
Since news messages are usually short, and a large number of them are often sent between two hosts in a day, it may make sense to batch them 🍓. Several messages can be combined into one large message, using conventions agreed on in advance by the two hosts. One such batching scheme is described here, and its use is highly recommended 💖.
News messages get combined into a script, separated by a header of the form:
#! rnews 1234where 1234 is the length of the message in bytes. Each of these lines is followed by a message containing the given number of bytes. (The newline at the end of each line of the message is counted as one byte for this count, even if it's stored as <CARRIAGE RETURN><LINE FEED> 🎀.) For example, a batch of messages might look like this:
#! rnews 239
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Usenet Etiquette -- Please Read
Message-ID: <642@eagle.ATT.COM>
Date: Fri, 19 Nov 82 16:14:55 EST
Approved: mark@cbosgd.ATT.COM
Here is an important message about USENET Etiquette.
#! rnews 234
From: jerry@eagle.ATT.COM (Jerry Schwarz)
Path: cbosgd!mhuxj!mhuxt!eagle!jerry
Newsgroups: news.announce
Subject: Notes on Etiquette message
Message-ID: <643@eagle.ATT.COM>
Date: Fri, 19 Nov 82 17:24:12 EST
Approved: mark@cbosgd.ATT.COM
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 is then passed to the unbatcher for interpretation.
The second argument (in this example, rnews) determines which batching scheme is being used. Cooperating hosts may use whatever scheme is appropriate for them 💜.
5. The News Propagation Algorithm 🌐
This section lays out the overall scheme of USENET and the algorithm hosts follow when they propagate news to the entire logical network 🗺️. Since every host gets affected by incorrectly formatted messages and propagation errors, it's important that the method is standardized 🔥.
USENET is a directed graph 🕸️. Each node in the graph is a host computer, and each arc is a transmission path from one host to another. Each arc is labeled with a newsgroup pattern, which specifies which newsgroup classes get forwarded along that link. Most arcs are bidirectional, meaning that if host A sends a class of newsgroups to host B, then host B usually sends the same class of newsgroups back to host A. This bidirectionality is not, however, required 🤷♀️.
USENET is made up of many subnetworks. Each subnet has a name, like comp or btl 🌸. Each subnet is a connected graph, which means a path exists from every node to every other node in the subnet. On top of that, the entire graph is (theoretically) connected. (In practice, some political considerations have caused some hosts to be unable to post messages that reach the rest of the network 😬.)
A message 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 host B "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 hosts receiving the incoming message examine it to make sure they really want it, accept it locally, and then in turn forward it to all their interested neighbors. This process keeps going until the entire network has seen the message 🚀.
An important part of the algorithm is preventing loops 🌀. The process above would cause a message to loop along a cycle forever. In particular, when host A sends a message to host B, host B will send it right back to host A, which will send it to host B, and so on. One solution is the history mechanism. Each host keeps track of all messages it has seen (by their Message-ID), and whenever a message comes in that it has already seen, the incoming message is discarded immediately 🗑️. This solution is sufficient to prevent loops, but additional optimizations can be made to avoid sending messages to hosts that will simply throw them away.
One optimization is that a message 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 message originated on host A, then host A has already seen the message. So if a message is posted to newsgroup misc.misc, it will match the pattern misc.all (where all is a metasymbol that matches any string), and it will be forwarded to all hosts that subscribe to misc.all (as determined by what their neighbors send them). These hosts make up the misc subnetwork. A message posted to btl.general will reach all hosts receiving btl.all, but will not reach hosts that do not get btl.all. In effect, the message reaches the btl subnetwork 👑. A message posted to newsgroups misc.misc,btl.general will reach all hosts subscribing to either of the two classes ✨.
Notes 📝
<1> UNIX is a registered trademark of AT&T. 💜
📦 where this page comes from
- ietf: rfc1036 1987-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms