RFC 977
Network News Transfer Protocol
RFC 977: Network News Transfer Protocol 💖
- Network Working Group 🌐
- Authors: Brian Kantor (U.C. San Diego) and Phil Lapsley (U.C. Berkeley) 🧑💻
- Date: February 1986 📅
- Category: Proposed Standard, "A Proposed Standard for the Stream-Based Transmission of News" 🎀
- Obsoletes / Updates: this header doesn't list either one 🌸
Status of This Memo 📣
okay bestie, so NNTP is the protocol for distributing, looking up, fetching, and posting news articles 📰 over a reliable stream-based transmission of news among the ARPA-Internet crowd. The big idea is that articles live in one central database, so every subscriber can pick out just the stuff they actually want to read ✨. Indexing, cross-referencing, and expiration of old messages are included too 🗂️. This RFC suggests a proposed protocol for the ARPA-Internet community and asks for discussion and suggestions for improvements 💬. Distribution of this memo is unlimited 🌈.
1. Introduction ✨
for years now, the ARPA-Internet community has been sharing bulletins, information, and data quickly with thousands of participants 🌍. We collectively call these items "news" 📰. News is how people get the rapid updates they need, like software bug fixes, new product reviews, technical tips, programming pointers, and fast-paced discussions about things working computer professionals care about 💻. News is very popular with its readers, and honestly, it's giving main character energy 🔥.
There are popularly two methods of distributing such news: the Internet method of direct mailing, and the USENET news system 💌.
1.1. Internet Mailing Lists 📬
the Internet community distributes news using mailing lists 📧. These are lists of subscriber mailbox addresses, plus remailing sublists of all the intended recipients. The lists work by remailing a copy of the information to every subscriber on the list 📨. This gets inefficient once a list grows beyond a dozen or so people 😩. Sending a separate copy to each subscriber eats up huge chunks of network bandwidth and CPU resources, plus a lot of disk storage at the destination host 💀. The list itself is also a headache to maintain, because people switch jobs, new subscribers join and old ones leave, and hosts come in and out of service 🙃.
1.2. The USENET News System 🗞️
a worthwhile reduction in those resources is possible if articles are stored in a central database on the receiving host instead of in each subscriber's mailbox 🧠. The USENET news system does exactly this. There's one central repository of news articles in one place (usually some kind of spool directory), plus a set of programs that let a subscriber pick out the items they want to read 📚. Indexing, cross-referencing, and expiration of aged messages are also provided ✅.
1.3. Central Storage of News 🗄️
for clusters of hosts connected by fast local area networks (like Ethernet), it makes even more sense to consolidate news onto one host, or a very few hosts 🖧. Access to the articles then works with a server and client model 💖. Subscribers can request only the articles they want to see, without wastefully duplicating a copy of every item on every host 🙌.
1.4. A Central News Server 🖥️
the way to get these savings is a central computer system that provides news service to the other systems on the local area network 🫶. This server manages the collection of news articles and index files, and each person who wants to read news does it over the LAN 👀. For a big cluster of computer systems, the savings in total disk space are clearly worth it 💅. This also lets workstations with limited disk storage take part in the news without incoming items eating up their disks 🦋.
We've heard rumors of somewhat successful attempts to provide centralized news service using IBIS and other shared or distributed file systems 🤔. A distributed file system might work well with a group of similar computers running nearly identical operating systems, but that kind of scheme isn't general enough to serve a wide range of client systems 😬. That's especially true when lots of different operating systems are in use among the clients. Very few (if any) shared or networked file systems offer the generality that stream connections over Internet TCP provide, especially when you consider the huge range of host hardware and operating systems 🌈.
NNTP specifies a protocol for the distribution, inquiry, retrieval, and posting of news articles using a reliable stream (such as TCP) server-client model 🎀. NNTP is designed so that news articles only need to be stored on one host (presumably a central one), and subscribers on other hosts attached to the LAN can read articles over stream connections to the news host 💜.
NNTP is modelled on the news article specifications in RFC 850, which describes the USENET news system 📖. But NNTP makes few demands on the structure, content, or storage of news articles, so we believe it can easily be adapted to other non-USENET news systems 🧚.
Typically, the NNTP server runs as a background process on one host, and accepts connections from other hosts on the LAN 🖲️. This works really well when there are a bunch of small computer systems (like workstations, with only one or at most a few users each) and one large central server 🍓.
1.5. Intermediate News Servers 🧁
for clusters of machines with lots of users (like you'd find in a university or a big industrial environment), an intermediate server might be used 🏫. This intermediate "slave" server runs on each computer system, and it handles news reading requests and does local caching of recently retrieved news articles 🗃️.
Typically, a client trying to get news service would first try to connect to the news service port on the local machine 🔌. If that attempt fails, which points to a failed server, an installation might either deny news access or allow a connection to the central "master" news server 🙈.
For workstations or other small systems, a direct connection to the master server would probably be the normal way of operating 💻.
This specification does not cover the operation of slave NNTP servers 🙅. We just suggest that slave servers are a logical addition to NNTP server usage that would improve things on large local area networks 💫.
1.6. News Distribution 🚚
NNTP has commands that provide a straightforward way to exchange articles between cooperating hosts 🤝. Hosts that are well connected on a local area or other fast network, and that want actual copies of news articles for local storage, might find NNTP to be a more efficient way to distribute news than more traditional transfer methods, like UUCP 🏎️.
In the traditional method, news gets propagated from host to host by flooding 🌊. That means each host sends all its new articles on to every host it feeds, and those hosts then pass the new articles along to the hosts they feed 🔁. Sending articles a host already got from another feed is clearly a waste of time and communication resources (lots of hosts are redundantly fed) 😤. But for transport mechanisms that are single-transaction based rather than interactive, like UUCP in the UNIX-world <1>, distribution time actually goes down when you send everything and let the receiving host discard the duplicates 🧹. This is especially true when communication sessions are limited to once a day 📆.
With NNTP, hosts exchanging news articles have an interactive mechanism for deciding which articles get transmitted 💅. A host that wants new news, or that has new news to send, will usually contact one or more of its neighbors using NNTP 📞. First, it asks if any new newsgroups have been created on the serving host, using the NEWGROUPS command 🆕. If there are some, and they're appropriate or wanted (as decided by local, site-dependent rules), those new newsgroups can be created 🎉.
Next, the client asks which new articles have arrived in all or some of the newsgroups it wants to receive, using the NEWNEWS command 👀. It gets a list of new articles back from the server, and can then request transmission of the ones it wants and doesn't already have 📥.
Finally, the client can tell the server which new articles it has recently received 🫡. The server indicates which articles it has already obtained copies of, and which articles should be sent to add to its collection 🧾.
This way, only the articles that aren't duplicates and that are wanted get transferred 🦋.
2. The NNTP Specification 📜
2.1. Overview 🔍
the news server specified by this document uses a stream connection (such as TCP) and SMTP-like commands and responses 💌. It's designed to accept connections from hosts and to provide a simple interface to the news database 🧩.
This server is only an interface between programs and the news databases 🔗. It doesn't do any user interaction or presentation-level functions 🙅♀️. Those "user-friendly" functions are better left to the client programs, which understand the environment they're running in much better 🫶.
When used via Internet TCP, the contact port assigned for this service is 119 🔢.
2.2. Character Codes 🔤
commands and replies are made up of characters from the ASCII character set 💫. When the transport service provides an 8-bit byte (octet) transmission channel, each 7-bit character is transmitted right justified in an octet, with the high order bit cleared to zero 🧮.
2.3. Commands ⌨️
commands consist of a command word, which in some cases may be followed by a parameter 🎯. Commands with parameters must separate the parameters from each other and from the command by one or more space or tab characters 🌸. Command lines must be complete with all required parameters, and may not contain more than one command 🚫.
commands and command parameters are not case sensitive 🙌. That means a command or parameter word can be upper case, lower case, or any mixture of the two, and it's all good ✨.
Each command line must be terminated by a CR-LF (Carriage Return - Line Feed) pair 🔚.
Command lines shall not exceed 512 characters in length, counting all characters including spaces, separators, punctuation, and the trailing CR-LF. That leaves 510 characters maximum for the command and its parameters 🧠. There is no provision for continuation command lines, so plan ahead, bestie 💀.
2.4. Responses 💬
responses come in two kinds, textual and status 🦋.
2.4.1. Text Responses 💬
okay bestie, text only gets sent AFTER a numeric status response line has gone out saying text is coming 📣. Then the text shows up as a bunch of successive lines, each ending in a CR-LF pair 🎀. To say "that's everything," the server sends a line with only a period (.) on it. Specifically: a CR-LF pair at the end of the last text line, then the period, then another CR-LF pair ✨.
If a line of the original text started with a period, that first period gets doubled 👯. So the client MUST examine the first character of every line it receives. For lines that start with a period, it has to figure out whether that's the end, or whether it should collapse the doubled period down to one 🧐.
The vibe here is that text messages are usually shown on the user's terminal, while command and status responses get interpreted by the client program before anything gets displayed 💅. Main character energy for the status lines, honestly 👑.
2.4.2. Status Responses 🚦
These are status reports from the server, and they tell you how the last command the client sent went 📬.
Status response lines start with a 3 digit numeric code, which is enough to tell every response apart 🔢. Some of them announce that text is on its way.
The first digit broadly tells you whether the previous command worked, failed, or is still in progress:
1xx - Informative message
2xx - Command ok
3xx - Command ok so far, send the rest of it.
4xx - Command was correct, but couldn't be performed for
some reason.
5xx - Command unimplemented, or incorrect, or a serious
program error occurred.The next digit is the function response category 🗂️:
x0x - Connection, setup, and miscellaneous messages
x1x - Newsgroup selection
x2x - Article selection
x3x - Distribution functions
x4x - Posting
x8x - Nonstandard (private implementation) extensions
x9x - Debugging outputThe exact response codes you should expect from each command SHOULD be listed in that command's description 📖. There's also a general set of response codes that can show up at any time, which is coming up next 🌸.
Certain status responses come with parameters like numbers and names. The number and type of those parameters is fixed for each response code, so it's super easy to interpret 🧠.
Parameters are separated from the numeric response code and from each other by a single space ✨. All numeric parameters are decimal, and they MAY have leading zeros 🔢. All string parameters begin after the separating space and end before the next separating space, or before the CR-LF pair at the end of the line. So string parameters may not contain spaces, which is a whole vibe 🫶. Any text in the response that isn't a parameter MUST follow the last parameter and be separated from it by a space. Also, the text after a response number MAY vary between server implementations, so the 3-digit numeric code SHOULD be what you use to figure out which response was sent 🎯.
Response codes that aren't specified in this standard MAY be used for any installation-specific extra commands that also aren't specified. Those SHOULD be picked to match the x8x pattern from above 🧩. (Also, debugging gets its own explicit home in the x9x codes 🐛.) Using unspecified response codes for standard commands is prohibited, so don't even 🙅♀️.
We set up the x9x pattern for debugging. Since a lot of debugging output counts as "informative messages," we'd expect responses 190 through 199 to be used for various debugging outputs 🧚. There's no requirement in this specification for debugging output. BUT if it does get provided over the connected stream, it MUST use these response codes 🚨. If it makes sense for a specific implementation, other x9x codes MAY be used for debugging too. (For example, 290 could be used to acknowledge a remote debugging request 💜.)
2.4.3. General Responses 🌈
Here's the list of general response codes the NNTP server may send 📋. They aren't tied to any one command. They MAY come back because of a connection, a failure, or some unusual situation 😵💫.
In general, 1xx codes MAY be ignored or displayed however you like 🙈. Code 200 or 201 gets sent on initial connection to the NNTP server, depending on whether posting is allowed 🎟️. Code 400 gets sent when the NNTP server shuts down service, like when an operator asks for it 🛑. And 5xx codes mean the command couldn't be performed for some unusual reason 💀.
100 help text
190
through
199 debug output
200 server ready - posting allowed
201 server ready - no posting allowed
400 service discontinued
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed3. Command and Response Details ⌨️
On the following pages you'll find descriptions of every command the NNTP server recognizes, plus the responses those commands get back 📚.
Each command is shown in upper case so it's easy to spot, even though the NNTP server ignores case when it interprets commands 🔠. Any parameters are shown in lower case. A parameter shown in [square brackets] is OPTIONAL. For example, [GMT] means the triglyph GMT MAY present or omitted 🕰️.
Every command described in this section MUST be implemented by all NNTP servers. No exceptions, periodt 💅.
Nothing stops anyone from adding more commands. HOWEVER, it is RECOMMENDED that any extra unspecified command begin with the letter "X", so it doesn't clash with later revisions of this specification 🦋.
Implementors, this is your reminder that these extra commands may not redefine specified status response codes 📝. Using extra unspecified responses for standard commands is also prohibited 🚫.
3.1. The ARTICLE, BODY, HEAD, and STAT commands 📰
There are two forms of the ARTICLE command (plus the related BODY, HEAD, and STAT commands) 👯. Each one picks the article a different way. When ARTICLE is followed by a message-id in angle brackets ("<" and ">"), the first form is used. When a numeric parameter is supplied, or no parameter at all, the second form gets invoked 🎯.
The text of the article comes back as a textual response, just like we covered earlier in this document ✨.
The HEAD and BODY commands are identical to ARTICLE, except they return only the header lines or only the text body of the article respectively 🧾.
The STAT command is similar to ARTICLE, except no text gets returned 🤫. When you select by message number within a group, STAT sets the current article pointer without sending any text. The acknowledgement response MAY contain the message-id, which may be of some value 💜. Using STAT to select by message-id is valid, but of questionable value, because a selection by message-id does NOT alter the "current article pointer" 🙃.
3.1.1. ARTICLE (selection by message-id) 🆔
ARTICLE <message-id>This displays the header, a blank line, and then the body (text) of the specified article 📄. The message-id is the message id of an article, as shown in that article's header. The client is expected to get the message-id from a list provided by the NEWNEWS command, from references inside another article, or from the message-id given in the response to some other command 🔍.
Please note that the internally-maintained "current article pointer" is NOT ALTERED by this command 🫠. This is so you can present articles that are referenced inside an article you're reading. It's also because figuring out the proper sequence and membership of an article that was posted to more than one newsgroup is semantically tricky 🌀.
3.1.2. ARTICLE (selection by number) 🔢
ARTICLE [nnn]This displays the header, a blank line, and then the body (text) of the current article or of the specified one 📑. The OPTIONAL parameter nnn is the numeric id of an article in the current newsgroup, and it MUST be chosen from the range of articles provided when the newsgroup was selected 🎯. If it's omitted, the current article is assumed 🫶.
The internally-maintained "current article pointer" is set by this command if a valid article number is specified 📍.
[The following applies to both forms of the ARTICLE command.] A response indicating the current article number, a message-id string, and that text is to follow will be returned 🎁.
The message-id string returned is an identification string inside angle brackets ("<" and ">"), derived from the header of the article itself 🪪. The Message-ID header line (REQUIRED by RFC850) from the article MUST be used to supply this information. If the message-id header line is missing from the article, a single digit "0" (zero) SHOULD be supplied inside the angle brackets 0️⃣.
Since the message-id field is unique to each article, a news reading program MAY use it to skip duplicate displays of articles that have been posted more than once, or posted to more than one newsgroup 🙌.
3.1.3. Responses 📬
220 n <a> article retrieved - head and body follow
(n = article number, <a> = message-id)
221 n <a> article retrieved - head follows
222 n <a> article retrieved - body follows
223 n <a> article retrieved - request text separately
412 no newsgroup has been selected
420 no current article has been selected
423 no such article number in this group
430 no such article found3.2. The GROUP command 📂
3.2.1. GROUP 🗃️
GROUP gggThe REQUIRED parameter ggg is the name of the newsgroup you want to select (e.g. "net.news") 🎯. You can get a list of valid newsgroups from the LIST command 📜.
The successful selection response returns the article numbers of the first and last articles in the group, plus an estimate of how many articles are on file in the group 📊. The estimate doesn't have to be exact, although exact is nice 💅. It MUST only be equal to or larger than the actual number of articles on file. (Some implementations really do count the articles on file, while others just subtract the first article number from the last one to get an estimate 🧮.)
When a valid group gets selected with this command, the internally maintained "current article pointer" is set to the first article in the group 📍. If an invalid group is specified, the previously selected group and article stay selected 🙅♀️. If an empty newsgroup is selected, the "current article pointer" is in an indeterminate state, and it SHOULD NOT be used 🫥.
Note that the name of the newsgroup is not case-dependent 🔤. Otherwise it MUST match a newsgroup from the LIST command, or you'll get an error 🚫.
3.2.2. Responses 📨
211 n f l s group selected
(n = estimated number of articles in group,
f = first article number in the group,
l = last article number in the group,
s = name of the group.)
411 no such news group3.3. The HELP command 🆘
3.3.1. HELP 💁♀️
HELPThis gives you a short summary of the commands this implementation of the server understands 📝. The help text comes back as a textual response, ending with a single period on a line by itself 🫶.
3.3.2. Responses 📨
100 help text follows3.4. The IHAVE command 📮
3.4.1. IHAVE 🎀
IHAVE <messageid>okay so IHAVE is how a client tells the server "hey, I've got an article with the id <messageid>!" 💌 If the server wants a copy, it sends back a response telling the client to send the whole thing. If the server isn't interested (like, it already has a copy 🙄), it sends back a response saying the article is not wanted.
If the server does want it, the client should send the entire article, header and body included, the same way it would for text transmission from the server. Then a response code comes back saying whether the transfer worked or didn't. ✨
This one is different from POST 💅 because IHAVE is for passing already-posted articles between hosts. It's not really for a personal newsreading program, normally. It also tells the server's news posting program, using the right settings (flags, options, etc.), that the incoming article is being forwarded from another host. Main character energy for servers 👑
The server still gets to change its mind, though. After looking more closely at the article, it can decide it's inappropriate and choose not to post or forward it. The 436 or 437 error codes can show up here, depending on what's going on. 🥲
Why would a server reject an article after all that? Stuff like inappropriate newsgroups or distributions, running out of disk space, article lengths, garbled headers, and so on. These are usually rules enforced by the server host's news software, not necessarily the NNTP server itself. 🧚
3.4.2. Responses 🌸
235 article transferred ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try againAn implementation note:
Some host news posting software can't always decide right away that an article is inappropriate for posting or forwarding. So it's acceptable to acknowledge a successful transfer and then quietly throw the article away later 🫣. That means it's permitted to send back the 235 code and discard the article afterwards. Honestly? It's not a fully satisfactory fix 😭. Maybe some implementations will want to email the article's author in certain of these cases 💌
3.5. The LAST command ✨
3.5.1. LAST 🦋
LASTThe internally maintained "current article pointer" moves back to the previous article in the current newsgroup 🔙. If you're already on the first article, you get an error message and the current article stays selected 🙃
The "current article pointer" is set by this command. (yes, it's said twice, it's that important 💅)
The server sends back a response with the current article number and a message-id string. No text is sent in response to this command. 🤫
3.5.2. Responses 💜
223 n a article retrieved - request text separately
(n = article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
422 no previous article in this group3.6. The LIST command 📋
3.6.1. LIST 🍓
LISTThis returns a list of valid newsgroups plus their info 🗂️. Each newsgroup gets sent as one line of text in this format:
group last first pHere <group> is the newsgroup name, <last> is the number of the last known article in it, <first> is the number of the first article currently in it, and <p> is either y or n 🎯. A y means posting to that group is allowed, and an n means it's prohibited.
The <first> and <last> fields will always be numeric, and they might have leading zeros 🔢. If <last> ends up smaller than <first>, that means there are no articles on file in the newsgroup right now.
Heads up though: even if LIST says posting is permitted to a group, the client can still be prohibited from posting 🚫. Check the POST command for the explanation of client prohibitions. The posting flag exists for each group because some are moderated or are digests, so you can't post there directly. Those articles have to be mailed to a moderator, who posts them on the submitter's behalf. This is separate from the posting permission the NNTP server grants to a client. 💁♀️
Also, an empty list is a totally possible valid response 🌵. That's when the text body is just the terminating period, and it means there are currently no valid newsgroups.
3.6.2. Responses 🌈
215 list of newsgroups follows3.7. The NEWGROUPS command 🆕
3.7.1. NEWGROUPS ⭐
NEWGROUPS date time [GMT] [<distributions>]This lists the newsgroups created since <date and time>, in the same format as LIST 📃.
The date is 6 digits in the format YYMMDD 📅. YY is the last two digits of the year, MM is the two-digit month (with a leading zero if needed), and DD is the day of the month (also with a leading zero if needed). The closest century gets assumed for the year, so 86 means 1986, 30 means 2030, 99 is 1999, and 00 is 2000. Wild that it just guesses the century for you 😤
Time has to be included too. It's 6 digits in the format HHMMSS, where HH is hours on the 24-hour clock, MM is minutes from 00-59, and SS is seconds from 00-59 ⏰. Time is assumed to be in the server's timezone, unless the token GMT appears. If GMT is there, both time and date are evaluated at the 0 meridian 🌍
The optional distributions parameter is a list of distribution groups, wrapped in angle brackets 🎁. If you include it, the distribution portion of a new newsgroup (like net in net.wombat) gets checked for a match with the listed categories, and only the matching new newsgroups get listed. If you want more than one distribution group, separate them with commas inside the angle brackets.
Empty list alert 🚨: it's a valid response too. The text body is only the terminating period, and that means there are currently no new newsgroups.
3.7.2. Responses 🫶
231 list of new newsgroups follows3.8. The NEWNEWS command 📨
3.8.1. NEWNEWS 💫
NEWNEWS newsgroups date time [GMT] [<distribution>]This gives you a list of message-ids for articles posted or received to the specified newsgroup since "date" 📬. The listing puts one message-id on each line, the same way text is sent. A single line containing just one period followed by CR-LF ends the list. ✋
Date and time use the same format as the NEWGROUPS command 🔁.
Now the fun part 🎉: a newsgroup name with a * (an asterisk) in it broadens the search to some or all newsgroups. The asterisk can match any part of a newsgroup name. For example, net.micro* matches net.micro.wombat, net.micro.apple, and so on. If you only give an asterisk as the newsgroup name, every newsgroup gets searched for new news 🌐
(Also, the asterisk expansion is a general replacement. So something like net.*.unix should expand properly to cover names like net.wombat.unix and net.whocares.unix. 🤌)
On the flip side, if there's no asterisk in a newsgroup name, only that one specified newsgroup gets searched for new articles 🎯. Newsgroup names have to come from the ones returned in the listing of available groups. You can name several newsgroups (asterisk included) in this command, separated by a comma. No comma should come after the last newsgroup in the list.
Implementors are cautioned to keep the 512 character command length limit in mind. ⚠️
The exclamation point (!) lets you negate a match 🙅♀️. That's how you leave certain newsgroups out of a bigger list. For example, the newsgroups specification net.*,mod.*,!mod.map.* means all net.<anything> and all mod.<anything> names get matched, EXCEPT mod.map.<anything> ones. If you use it, the exclamation point has to be the very first character of the newsgroup name or pattern. Super specific, but important 🥹
The optional distributions parameter is also a list of distribution groups in angle brackets 🎀. If you include it, the distribution portion of an article's newsgroup (like net in net.wombat) gets checked for a match with the categories you listed. Only articles with at least one newsgroup belonging to that distributions list get listed. If you're supplying more than one distribution group, separate them with commas inside the angle brackets.
The use of the IHAVE, NEWNEWS, and NEWGROUPS commands to distribute news is discussed in an earlier part of this document 📚
Empty list again 💤: it's a possible valid response, and it means there is currently no new news. The text body is just the terminating period.
3.8.2. Responses 🌷
230 list of new articles by message-id follows3.9. The NEXT command ⏭️
3.9.1. NEXT 💖
NEXTThe internally maintained "current article pointer" moves forward to the next article in the current newsgroup 🏃♀️. If there are no more articles left in the current group, you get an error message and the current article stays selected 😬
The "current article pointer" is set by this command.
The server sends back a response with the current article number and the message-id string. No text is sent in response to this command. 🤐
3.9.2. Responses 🧚
223 n a article retrieved - request text separately
(n = article number, a = unique article id)
412 no newsgroup selected
420 no current article has been selected
421 no next article in this group3.10. The POST command 📝✨
3.10.1. POST 💌
Okay bestie, this is the posting command 📮 If posting is allowed, the server returns response code 340, which basically means "yep, send me the article now" 🫶 Response code 440 means posting is prohibited for some installation-dependent reason 🙈
If posting is permitted, the article should be presented in the format specified by RFC850, and it should include all required header lines ✨ Once the client has completely sent the article's header and body to the server, the server returns another response code to say whether the posting worked 💅
The text for the header and body should be sent using the same conventions the client uses for text received from the news server. A single period (".") on a line marks the end of the text, and any line in the original text that starts with a period gets that period doubled during transmission 🦋
No attempt shall be made by the server to filter characters, fold or limit lines, or otherwise process incoming text. The idea is that the server just passes the incoming message to the server installation's news posting software, which is separate from this specification 🌸 For more details, see RFC850 💜
Most installations will want the client news program to let the user write their message in some kind of text editor and only send it to the server for posting after it's fully composed 📝 So the client should take note of the herald message that greeted it when the connection was first established ✨ That message says whether postings from that client are permitted, and it can be used to warn the user that their access is read-only if that's the case 🫣 This stops the user from wasting a ton of time writing a message only to find out posting was denied 😭 How clients and hosts are determined to be allowed to post is installation dependent, and this specification doesn't cover it 🌈
3.10.2. Responses 📬
240 article posted ok
340 send article to be posted. End with <CR-LF>.<CR-LF>
440 posting not allowed
441 posting failed
(for reference, one of the following codes will be sent upon initial
connection; the client program should determine whether posting is
generally permitted from these:) 200 server ready - posting allowed
201 server ready - no posting allowed3.11. The QUIT command 🚪
3.11.1. QUIT 👋
QUITThe server acknowledges the QUIT command and then closes the connection to the client 💖 This is the preferred way for a client to say it has finished all of its transactions with the NNTP server 🫶
If a client just disconnects (or the connection times out, or some other fault happens), the server should gracefully stop trying to serve that client 🧚
3.11.2. Responses 📭
205 closing connection - goodbye!3.12. The SLAVE command 🧸
3.12.1. SLAVE 🎀
SLAVEThis tells the server that this client connection goes to a slave server, rather than to a user 👑
This command is meant for telling apart connections from single users and connections from subsidiary ("slave") servers 🦋 It can be used to say that requests from this client should get priority, since it's presumably serving more than one person 💅 It might also help decide which connections to close when system load levels are exceeded, maybe by favouring slave servers 🌸 What this command actually gets used for is entirely implementation dependent, and it may vary from one host to another 🌈 Even NNTP servers that don't give slave servers priority must still recognize and acknowledge this command 🫶
3.12.2. Responses 📨
202 slave status noted4. Sample Conversations 🎬
These are samples of the conversations you might expect with the news server in hypothetical sessions 💜 C: marks commands sent from the client program to the news server, and S: marks responses the client gets back from the server 🦋
4.1. Example 1 - relative access with NEXT 🌸
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 wombatvax news server ready - posting ok
(client asks for a current newsgroup list)
C: LIST
S: 215 list of newsgroups follows
S: net.wombats 00543 00501 y
S: net.unix-wizards 10125 10011 y
(more information here)
S: net.idiots 00100 00001 n
S: .
(client selects a newsgroup)
C: GROUP net.unix-wizards
S: 211 104 10011 10125 net.unix-wizards group selected
(there are 104 articles on file, from 10011 to 10125)
(client selects an article to read)
C: STAT 10110
S: 223 10110 <23445@sdcsvax.ARPA> article retrieved - statistics
only (article 10110 selected, its message-id is
<23445@sdcsvax.ARPA>)
(client examines the header)
C: HEAD
S: 221 10110 <23445@sdcsvax.ARPA> article retrieved - head
follows (text of the header appears here)
S: .
(client wants to see the text body of the article)
C: BODY
S: 222 10110 <23445@sdcsvax.ARPA> article retrieved - body
follows (body text here)
S: .
(client selects next article in group)
C: NEXT
S: 223 10113 <21495@nudebch.uucp> article retrieved - statistics
only (article 10113 was next in group)
(client finishes session)
C: QUIT
S: 205 goodbye.4.2. Example 2 - absolute article access with ARTICLE 🎈
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 UCB-VAX netnews server ready -- no posting allowed
C: GROUP msgs
S: 211 103 402 504 msgs Your new group is msgs
(there are 103 articles, from 402 to 504)
C: ARTICLE 401
S: 423 No such article in this newsgroup
C: ARTICLE 402
S: 220 402 <4105@ucbvax.ARPA> Article retrieved, text follows
S: (article header and body follow)
S: .
C: HEAD 403
S: 221 403 <3108@mcvax.UUCP> Article retrieved, header follows
S: (article header follows)
S: .
C: QUIT
S: 205 UCB-VAX news server closing connection. Goodbye.4.3. Example 3 - NEWGROUPS command 🍓
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 Imaginary Institute News Server ready (posting ok)
(client asks for new newsgroups since April 3, 1985)
C: NEWGROUPS 850403 020000
S: 231 New newsgroups since 03/04/85 02:00:00 follow
S: net.music.gdead
S: net.games.sources
S: .
C: GROUP net.music.gdead
S: 211 0 1 1 net.music.gdead Newsgroup selected
(there are no articles in that newsgroup, and
the first and last article numbers should be ignored)
C: QUIT
S: 205 Imaginary Institute news server ceasing service. Bye!4.4. Example 4 - posting a news article ✍️
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 200 BANZAIVAX news server ready, posting allowed.
C: POST
S: 340 Continue posting; Period on a line by itself to end
C: (transmits news article in RFC850 format)
C: .
S: 240 Article posted successfully.
C: QUIT
S: 205 BANZAIVAX closing connection. Goodbye.4.5. Example 5 - interruption due to operator request 🙈
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 genericvax news server ready, no posting allowed.
(assume normal conversation for some time, and
that a newsgroup has been selected)
C: NEXT
S: 223 1013 <5734@mcvax.UUCP> Article retrieved; text separate.
C: HEAD
C: 221 1013 <5734@mcvax.UUCP> Article retrieved; head follows.
S: (sends head of article, but halfway through is
interrupted by an operator request. The following
then occurs, without client intervention.)
S: (ends current line with a CR-LF pair)
S: .
S: 400 Connection closed by operator. Goodbye.
S: (closes connection)4.6. Example 6 - Using the news server to distribute news between systems. 🌍
S: (listens at TCP port 119)
C: (requests connection on TCP port 119)
S: 201 Foobar NNTP server ready (no posting)
(client asks for new newsgroups since 2 am, May 15, 1985)
C: NEWGROUPS 850515 020000
S: 235 New newsgroups since 850515 follow
S: net.fluff
S: net.lint
S: .
(client asks for new news articles since 2 am, May 15, 1985)
C: NEWNEWS * 850515 020000
S: 230 New news since 850515 020000 follows
S: <1772@foo.UUCP>
S: <87623@baz.UUCP>
S: <17872@GOLD.CSNET>
S: .
(client asks for article <1772@foo.UUCP>)
C: ARTICLE <1772@foo.UUCP>
S: 220 <1772@foo.UUCP> All of article follows
S: (sends entire message)
S: .
(client asks for article <87623@baz.UUCP>
C: ARTICLE <87623@baz.UUCP>
S: 220 <87623@baz.UUCP> All of article follows
S: (sends entire message)
S: .
(client asks for article <17872@GOLD.CSNET>
C: ARTICLE <17872@GOLD.CSNET>
S: 220 <17872@GOLD.CSNET> All of article follows
S: (sends entire message)
S: .
(client offers an article it has received recently)
C: IHAVE <4105@ucbvax.ARPA>
S: 435 Already seen that one, where you been?
(client offers another article)
C: IHAVE <4106@ucbvax.ARPA>
S: 335 News to me! <CRLF.CRLF> to end.
C: (sends article)
C: .
S: 235 Article transferred successfully. Thanks.
(or)
S: 436 Transfer failed.
(client is all through with the session)
C: QUIT
S: 205 Foobar NNTP server bids you farewell.4.7. Summary of commands and responses. 📋
The following are the commands the NNTP server recognizes, and the responses it returns 💅
4.7.1. Commands ⌨️
ARTICLEBODYGROUPHEADHELPIHAVELASTLISTNEWGROUPSNEWNEWSNEXTPOSTQUITSLAVESTAT
4.7.2. Responses 🔥
100 help text follows
199 debug output
200 server ready - posting allowed
201 server ready - no posting allowed
202 slave status noted
205 closing connection - goodbye!
211 n f l s group selected
215 list of newsgroups follows
220 n <a> article retrieved - head and body follow 221 n <a> article
retrieved - head follows
222 n <a> article retrieved - body follows
223 n <a> article retrieved - request text separately 230 list of new
articles by message-id follows
231 list of new newsgroups follows
235 article transferred ok
240 article posted ok
335 send article to be transferred. End with <CR-LF>.<CR-LF>
340 send article to be posted. End with <CR-LF>.<CR-LF>
400 service discontinued
411 no such news group
412 no newsgroup has been selected
420 no current article has been selected
421 no next article in this group
422 no previous article in this group
423 no such article number in this group
430 no such article found
435 article not wanted - do not send it
436 transfer failed - try again later
437 article rejected - do not try again.
440 posting not allowed
441 posting failed
500 command not recognized
501 command syntax error
502 access restriction or permission denied
503 program fault - command not performed4.8. A Brief Word about the USENET News System 📰
Okay so, in the UNIX world (which traditionally ran on 1200 baud dial-up telephone lines 📞), the USENET News system evolved to handle central storage, indexing, retrieval, and distribution of news. Apart from its underlying transport mechanism (UUCP), USENET News is an efficient way to give news and bulletin service to subscribers on UNIX and other hosts worldwide 🌍. It's discussed in detail in RFC 850, runs on most versions of UNIX and plenty of other operating systems, and is customarily distributed without charge 💖.
USENET keeps a spooling area on the UNIX host to store news articles, one article per file 🗂️. Each article starts with a series of heading text lines, which hold the sender's identification and organizational affiliation, timestamps, electronic mail reply paths, the subject, the newsgroup (the subject category), and so on ✨. Here's a complete news article, reproduced in its entirety so you can see it in action. For more details, consult RFC 850 🧚.
Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site
sdcsvax.UUCP
Posting-Version: version B 2.10.1 6/24/83 SMI; site unitek.uucp
Path:sdcsvax!sdcrdcf!hplabs!qantel!ihnp4!alberta!ubc-vision!unitek
!honman
From: honman@unitek.uucp (Man Wong)
Newsgroups: net.unix-wizards
Subject: foreground -> background ?
Message-ID: <167@unitek.uucp>
Date: 25 Sep 85 23:51:52 GMT
Date-Received: 29 Sep 85 09:54:48 GMT
Reply-To: honman@unitek.UUCP (Hon-Man Wong)
Distribution: net.all
Organization: Unitek Technologies Corporation
Lines: 12
I have a process (C program) which generates a child and waits for
it to return. What I would like to do is to be able to run the
child process interactively for a while before kicking itself into
the background so I can return to the parent process (while the
child process is RUNNING in the background). Can it be done? And
if it can, how?
Please reply by E-mail. Thanks in advance.
Hon-Man Wong5. References 🔖
- [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC-822, Department of Electrical Engineering, University of Delaware, August, 1982.
- [2] Horton, M., "Standard for Interchange of USENET Messages", RFC-850, USENET Project, June, 1983.
- [3] Postel, J., "Transmission Control Protocol- DARPA Internet Program Protocol Specification", RFC-793, USC/Information Sciences Institute, September, 1981.
- [4] Postel, J., "Simple Mail Transfer Protocol", RFC-821, USC/Information Sciences Institute, August, 1982.
6. Acknowledgements 🫶
The authors want to send heartfelt thanks to the many people who helped with this specification 💜. Special shoutout to Erik Fair and Chuq von Rospach, because without their inspiration this whole thing wouldn't have happened at all 👑.
7. Notes 📝
<1>UNIX is a trademark of Bell Laboratories. 💅
📦 where this page comes from
- ietf: rfc977 1986-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms