RFC 2980

Common NNTP Extensions

📅 published October 2000, from ietf

RFC 2980: Common NNTP Extensions ✨

Okay bestie, this is RFC 2980, and it's giving a whole reference guide to the popular add-ons people bolted onto NNTP 💖

The title block is the tea 🫖 It's from the Network Working Group, written by S. Barber at Academ Consulting Services, and it's dated October 2000. The category is Informational, so it's documenting stuff, not making it a standard 🎀 The header doesn't list anything it obsoletes or updates ✨

Status of This Memo 🦋

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract 🍓

So this doc covers a bunch of popular extensions to the Network News Transfer Protocol (NNTP) from RFC 977. It's not a standard, but the hope is that it'll be a handy reference for future NNTP implementers 🧚 That could also help different implementations that use extensions play nicely together, which is a big mood 🫶

Introduction 💜

Okay so RFC 977 [1] defined NNTP over a decade ago, and NNTP is now one of the most popular protocols on the Internet 🔥 Loads of implementations exist on tons of platforms and operating systems. Work on a revision started in 1991, but it never turned into a new standard. Still, a lot of those ideas ended up in real NNTP implementations anyway ✨ Newsreader authors also made their own extensions, and people use those too.

This document is trying to capture and define all the known extensions that are in official NNTP server releases as of when it was written. Where possible, it notes which server software first implemented each extension 💅 The author's hope is that using this doc alongside RFC 977 will stop people from making new extensions that basically do the same thing as existing ones 🙈 Software devs can also use this doc and others [2] as a resource when building new stuff.

This doc does NOT specify an Internet Standard of any kind. It only tries to document current practices 🎀 It might clear up some confusion in RFC 977, but RFC 977 is still the authority in every case 👑 Some implementations aren't strictly RFC 977 compliant, and where that matters, the doc points out the deviations. This doc also reflects the work of the IETF NNTP-EXT working group, chaired by Ned Freed and Stan Barber 🌈

The whole point is to give implementers one uniform source of info about extensions. But anyone thinking about implementing these needs to know that the extensions listed here are NOT part of any current NNTP standard 😭 Some of them also shouldn't be put into new NNTP implementations, because they're no longer used in modern NNTP environments 💀 Those commands count as historic, and the doc labels them that way.

Extensions fall into three categories: transport, newsreader and other ✨ Transport extensions were added specifically to move news articles from one server to another 🚚 Newsreader extensions help NNTP clients pick out and fetch articles from servers 📰 Other covers anything that doesn't fit those two, like authentication and time-of-day extensions 🧚 For each command, the format from section 3 of RFC 977 gets used 💖

1. Transport Extensions 🚚

A transport extension is one that's mainly used for communication between servers. Below you'll find the descriptions of each transport extension command, plus the responses those commands send back 🫶

Commands are written in upper case for clarity, but the NNTP server ignores case when it interprets them 💅 Parameters are written in lower case. A parameter in [square brackets] is optional. For example, [GMT] means the triglyph GMT may be present or omitted. A parameter that can be repeated is followed by an ellipsis 🌸

1.1.1 The CHECK command 💌

CHECK <message-id>

Okay so CHECK is how a peer finds out whether the article with the given message-id should be sent to the server with the TAKETHIS command 🦋 The peer doesn't have to wait for a response before sending the next command, which is so efficient 🔥

Once you've got the responses to a bunch of CHECK commands, you can build a list of articles to send later with TAKETHIS ✨

Using CHECK for streaming is optional 🎀 Some implementations just go straight to TAKETHIS and send everything in the send queue for that peer to the server.

On some implementations, CHECK isn't allowed when the server is in slave mode (set up with the SLAVE command) 🙈

Responses in the form X3X have to include the message-id in the response 💜

1.1.2. Responses 🍓

238 no such article found, please send it to me
400 not accepting articles
431 try sending it again later
438 already have it, please don't send it to me
480 Transfer permission denied
500 Command not understood

1.2.1 The MODE STREAM command 🧚

MODE STREAM

MODE STREAM is how a peer tells the server it wants to drop the lock-step, back-and-forth conversation style of NNTP and send commands in streams 🌈 It should be used before TAKETHIS and CHECK. Check out the TAKETHIS and CHECK sections for more details 💖

1.2.2. Responses 🎀

203 Streaming is OK
500 Command not understood

1.3.1 The TAKETHIS command 🚀

TAKETHIS <message-id>

TAKETHIS sends articles to a server while in streaming mode 💅 The whole article (header first, then body) gets sent right after the peer sends the TAKETHIS command. The peer doesn't wait for a response before sending the next command and its article, so it's giving speed ⚡

While the article is going out, the peer should send the entire article, header and body included, the way text transmission from the server is specified. See Section 2.4.1 of RFC 977 for details ✨

Responses in the form X3X have to include the message-id in the response 🫶

1.3.2. Responses 🌸

239 article transferred ok
400 not accepting articles
439 article transfer failed
480 Transfer permission denied
500 Command not understood

1.4.1 The XREPLIC command 🪄

XREPLIC ggg:nnn[,ggg:nnn...]

XREPLIC lets you exactly copy the news spool structure of one server onto another server 🤯 It first showed up in INN.

It works a lot like the IHAVE command from RFC 977, and it uses the same response codes 💕 The command line arguments are entries separated by a single comma. Each entry is a news group name, a colon, and an article number 📝 If the server replies with a 335 response, the article should be filed in the news group(s) and article number(s) given on the XREPLIC command line. If the server can't successfully install the article after accepting it, it can send a 436 or 437 response code to show the failure 😭

This command should only be used when the receiving server is fed by just one other server. Honestly, when it's used with servers that have multiple feeds, it'll probably fail a lot 💀

XREPLIC slaving was deprecated in INN version 1.7.2 and later 🙈 INN can now slave servers in a transparent way, just by transferring the article's Xref header. (In earlier versions, that header was made locally and stripped off on outgoing feeds.)

It's likely that future versions of INN won't support XREPLIC anymore 🥀

1.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 again

2. Newsreader Extensions 📰

Newsreader extensions are the ones mainly used by newsreading clients. Below are the descriptions of each newsreader extension command, plus the responses those commands send back 💖

The same formatting rules apply here: commands are upper case, parameters are lower case, and [square brackets] mean optional. Repeatable parameters get an ellipsis. Mutually exclusive parameters are separated by a vertical bar (|). For example, ggg|<message-id> means a group name or a <message-id> can be specified, but not both 🫶 Some parameters, especially <message-id>, are case specific. See RFC 1036 for those details 🧐

Some commands also use a pattern to select multiple news groups. The pattern is always based on the wildmat [4] format that Rich Salz introduced in 1986 🌈 Arguments that should be in wildmat format are written as wildmat. Section 3.3 of this document goes into wildmat in detail 💅

2.1.1 Extensions to the LIST command 🪞

The original LIST command in RFC 977 took no arguments and returned the contents of the active file in a specific format 📜 The early newsreaders used other info from the news transport software besides the active file, so people made extensions to LIST to give newsreaders access to that info ✨ Other LIST extensions might just return the contents of a file. The doc suggests this approach over adding more verbs. For example, LIST MOTD could be used instead of adding XMOTD 🧚

2.1.2 LIST ACTIVE 🌟

LIST ACTIVE [wildmat]

LIST ACTIVE works exactly like the LIST command in RFC 977 🎀 The responses and the format should match the no-argument LIST command exactly. If the optional matching parameter is given, the list only includes groups that match the pattern. A single group is usually very efficient for the server, and multiple groups can be specified with wildmat patterns (described later in this document), not regular expressions 💖 If nothing matches, you get an empty list, not an error 🙌 This command first appeared in the UNIX reference version.

2.1.3. LIST ACTIVE.TIMES ⏰

LIST ACTIVE.TIMES

Okay so the active.times file is kept by some news transport systems 📅 and it's basically the "who made this group and when" file. 💅 It generally has three fields. The first is the name of the news group. The second is the time the group was created on this news server, counted in seconds since January 1, 1970. The third is the email address of whoever created the group. 💌 When you run it, the info shows up right after the 215 response. Once everything's displayed, the server sends a period on a line by itself. If the info isn't available, the server gives you the 503 error response. This command first appeared in the UNIX reference version 🦋

2.1.3.1. Responses

215 information follows
503 program error, function not performed

2.1.4. LIST DISTRIBUTIONS 🌈

LIST DISTRIBUTIONS

The distributions file is kept by some news transport systems too, and it's giving "valid values" energy ✨. It tells you which values are allowed in the Distribution: line of a news article header, and what each value actually means. Each line has two fields: the value and a short explanation of it. When you run this, the info is displayed right after the 215 response. When display is completed, the server sends a period on a line by itself. If the info isn't available, the server returns the 503 error response. This command first appeared in the UNIX reference version 🌸

2.1.4.1. Responses

215 information follows
503 program error, function not performed

2.1.5. LIST DISTRIB.PATS 🎀

LIST DISTRIB.PATS

The distrib.pats file is kept by some news transport systems and it's the default-setter bestie 🫶. It holds default values for the Distribution: line when people post to particular news groups. This info could be used to fill in a default Distribution: line when you're posting an article. Each entry has three fields separated by colons. The first is a weight. The second is a group name, or a pattern that can match a group name using the wildmat format. The third is the value that should go in the Distribution: line when the group name matches and the weight is the highest. 👑 All of this processing is done by the news posting client, not the server. The server just hands the info over, and the client can use it or ignore it as it chooses 🧚 When you run it, the info is displayed right after the 215 response. When display is completed, the server sends a period on a line by itself. If the info isn't available, the server returns the 503 error response. This command first appeared in INN 💜

2.1.5.1. Responses

215 information follows
503 program error, function not performed

2.1.6. LIST NEWSGROUPS 📰

LIST NEWSGROUPS [wildmat]

The newsgroups file is kept by some news transport systems, and it's the directory of every active group on the server 📚 Each line has two fields: the news group name, and a short explanation of what that group is for. When you run it, the info is displayed right after the 215 response. When display is completed, the server sends a period on a line by itself. If the info isn't available, the server returns the 503 response. If you add the optional matching parameter, the list only includes groups that match the pattern. Matching doesn't look at the group descriptions, just the names 🙈 Asking for a single group is usually super efficient for the server. You can also use multiple groups by writing wildmat patterns, which are similar to file globbing and not regular expressions. If nothing matches, you get an empty list back, not an error 🍓

When the optional parameter is specified, this command is equivalent to the XGTITLE command, though the response codes are different 🔥

2.1.6.1. Responses

215 information follows
503 program error, function not performed

2.1.7. LIST OVERVIEW.FMT 📋

LIST OVERVIEW.FMT

The overview.fmt file is kept by some news transport systems, and it tells you the order that header info is stored in the overview databases for each news group 🗂️ When you run it, the news article header fields are displayed one line at a time, in the same order they're stored in the overview database [5], right after the 215 response. When display is completed, the server sends a period on a line by itself. If the info isn't available, the server returns the 503 response.

Heads up: if a header has the word "full" (without quotes) after the colon, the header's name gets added to the front of its field in the output the server sends back 👀

Many newsreaders work better if Xref: is one of the optional fields 💖

It is STRONGLY recommended that this command be implemented on any server that implements the XOVER command. 😭 See section 2.8 for more details about the XOVER command.

2.1.7.1. Responses

215 information follows
503 program error, function not performed

2.1.8. LIST SUBSCRIPTIONS 🌟

LIST SUBSCRIPTIONS

This command gets the default subscription list for new users of this server. The order of the groups matters ⭐

When this list is available, it comes after the 215 response and is followed by a period on a line by itself. When the list isn't available, the server returns a 503 response code.

2.1.8.1. Responses

215 information follows
503 program error, function not performed

2.2. LISTGROUP 🦢

LISTGROUP [ggg]

The LISTGROUP command gets you a list of all the article numbers in a particular news group. It's a whole vibe 🫧

The optional parameter ggg is the name of the news group to select, for example "news.software.b". You can get a list of valid news groups from the LIST command. If you don't specify a group, the current group is used as the default argument.

When the command works, the response is a list of the article numbers in the group, followed by a period on a line by itself.

When you select a valid group with this command, the internally maintained "current article pointer" is set to the first article in the group. If you specify an invalid group, the previously selected group and article stay selected. If you select an empty news group, the "current article pointer" is in an indeterminate state and should not be used 🙃

Note that the news group name is not case-dependent. Otherwise it has to match a news group you got from the LIST command, or you'll get an error 💀

2.2.1. Responses

211 list of article numbers follow
412 Not currently in newsgroup
502 no permission

2.3. MODE READER 🎧

MODE READER

MODE READER is how a client tells the server that it's a news reading client 🎀 Some implementations use this info to reconfigure themselves for better performance when responding to news reader commands. This command can be contrasted with the SLAVE command in RFC 977, which was not widely implemented. MODE READER first became available in INN 🌷

2.3.1. Responses

200 Hello, you can post
201 Hello, you can't post

2.4. XGTITLE 📝

XGTITLE [wildmat]

The XGTITLE command is used to retrieve news group descriptions for specific news groups 🔍

This extension first appeared in ANU-NEWS, an NNTP implementation for DEC's VMS 🖥️ The optional parameter is a pattern in wildmat format. When it runs, you get a 282 response, followed by lines with two fields: the news group name (which matches the pattern in the argument) and a short explanation of what the news group is for. If you don't give an argument, the default argument is the current group name. When display is completed, the server sends a period on a line by itself.

Please note that this command and the LIST NEWSGROUP command do the same job, just with different response codes 🤓

Since this command does the same thing as LIST NEWSGROUP, it is suggested that this extension be deprecated and no longer be used in newsreading clients 🥀

Note that one of the response codes from XGTITLE conflicts with some of the authentication extensions ⚠️

2.5.1. Responses

481 Groups and descriptions unavailable
282 list of groups and descriptions follows

2.6. XHDR 🧾

XHDR header [range|<message-id>]

The XHDR command is used to pull specific headers from specific articles 🎯

The required parameter is the name of a header line, like "subject", in a news group article. See RFC 1036 for a list of valid header lines. The optional range argument can be any of these:

an article number
an article number followed by a dash to indicate
   all following
an article number followed by a dash followed by
   another article number

The optional message-id argument points to a specific article. The range and message-id arguments are mutually exclusive, so you can't use both at once 🙅‍♀️ If you don't specify either one, the info comes from the current article. A successful response starts with a 221 response, followed by the matched headers from all the matched messages. Each line with matched headers has an article number (or a message ID, if you used one in the command), then one or more spaces, then the value of the requested header in that article. When the output is complete, a period goes on a line by itself. If you give a message-id and no such article exists, you get the 430 error response. If you give a range, a news group must have been selected earlier, or you get a 412 error response. If no articles are in the range you asked for, the server returns a 420 error response. A 502 response comes back if the client only has permission to transfer articles 🚫

Some implementations return "(none)" followed by a period on a line by itself if no headers match in any of the articles searched. Others return the 221 response code followed by a period on a line by itself 🤷‍♀️

The XHDR command has been in the UNIX reference implementation since its first release. Until now, though, it was only documented in the source for the server 📜

2.6.1. Responses

221 Header follows
412 No news group current selected
420 No current article selected
430 no such article
502 no permission

2.7 XINDEX 🧚

okay so XINDEX is giving full retro newsreader energy 📰 it asks the server for an index file in the format originally made for the TIN [6] news reader 💅

XINDEX ggg

the required ggg parameter is the name of the news group you want to select, like "news.software.b" 🫶 if you're not sure what groups exist, LIST is your bestie, because that's where you get the list of valid news groups ✨

if the selection works, you get back the index file in TIN format, and then a period on a line by itself to signal the end 🎀

when a valid group gets selected this way, the internal "current article pointer" jumps to the first article in the group 🦋 but if you give it an invalid group, the previously selected group and article just stay selected, so nothing gets messed up 🙈 and if the group is empty, the "current article pointer" is in an indeterminate state and should not be used 💀 so don't go poking at it!!

the group name is not case-dependent, so "NEWS.SOFTWARE.B" works just fine 🌈 otherwise it has to match a news group you got from LIST, or you'll get an error 😭

the TIN-style index format is explained in the TIN newsreader documentation, not here 📖 and since newer TIN versions support the news overview (NOV) format, it is recommended that this extension become historic and no longer be used in current servers or future implementations 🍓 very much a "we've moved on" moment 💜

2.7.1 Responses

218 tin-style index follows
418 no tin-style index is available for this news group

2.8 XOVER 🌸

XOVER [range]

XOVER returns info from the overview database for the article(s) you asked for 🧚 this idea came from "The Design of a Common Newsgroup Overview Database for Newsreaders" by Geoff Collyer, which is distributed in the Cnews distribution, so shoutout to him 🙌 the optional range argument can be any of these:

  • an article number
  • an article number followed by a dash to indicate all following
  • an article number followed by a dash followed by another article number

if you don't give any argument, you get info for the current article 💖 a successful response starts with a 224 response, then the overview info for all the matched messages, and then a period on a line by itself once it's done ✨ you need to have selected a news group earlier, or you get a 412 error 😭 if no articles are in your range, the server sends a 420 error 💀 and if you only have permission to transfer articles, you get a 502 response 🔒

each line of output is the article number, followed by each header from the overview database (or the article itself, if the data isn't in the overview database), all separated by a tab character 🎀 the fields have to come in this exact order: subject, author, date, message-id, references, byte count, and line count 👑 optional fields can come after line count 💅 you figure out which optional fields are there, and in what order, by reading the LIST OVERVIEW.FMT response 🦋 if there's no data for a field, you still have to put in a null field, so you'll see two tab characters right next to each other 🙈 and servers should not output fields for articles that were removed after the XOVER database was made 🫶

if XOVER is implemented, LIST OVERVIEW.FMT should be implemented too, since that's how clients figure out which fields XOVER will give back and in what order 🌈 see Section 2.1.7 for the full tea on LIST OVERVIEW.FMT ☕

and one more thing: any tab or end-of-line characters in returned header data get turned into a space character 🧼

2.8.1 Responses

224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission

2.9 XPAT 🦋

XPAT header range|<message-id> pat [pat...]

XPAT pulls specific headers from specific articles, but only the ones where the pattern matches the header contents 💅 this one first showed up in INN ✨

the required header parameter is the name of a header line, like "subject" 💖 for a list of valid header lines, check RFC 1036 📚 the required range argument can be any of these:

  • an article number
  • an article number followed by a dash to indicate all following
  • an article number followed by a dash followed by another article number

the required message-id argument points at one specific article 🎯 range and message-id are mutually exclusive, so you can't use both at once 🙅 at least one pattern in wildmat must be specified too 🌸 if there are extra arguments, they get joined together with a single space to make one full pattern 🧩

a successful response starts with a 221 response, then the headers from every message where the pattern matched the contents of that header line 🎀 an empty list counts as a success too 👑 once it's done, you get a period on a line by itself 🍓 if the optional argument is a message-id and no such article exists, you get a 430 error 😭 and if you only have permission to transfer articles, it's a 502 response 🔒

2.9.1 Responses

221 Header follows
430 no such article
502 no permission

2.10 The XPATH command 🧚

XPATH <message-id>

XPATH tells you which filenames an article is filed under 📂 it first appeared in INN too, so INN really had a moment 🌈

the required parameter message-id is the message id of an article, the same one shown in that article's message-id header 💖 according to RFC 1036 [3], every message id across the netnews environment is unique, but articles can be crossposted to multiple groups 🦋 the response to XPATH is either a listing of every filename where the article is stored, separated by spaces, or a response saying no article with that message-id exists 🫶 the returned data is only useful if the client knows the server's implementation details 🙈 so, because of that, it is recommended that clients avoid using this command 💅

2.10.1 Responses

223 path1[ path2 ...]
430 no such article on server

2.11 The XROVER command 🌸

XROVER [range]

XROVER returns reference info from the overview database for the article(s) you asked for 🔥 it first appeared in the Unix reference implementation 🧚 the optional range argument can be any of these:

  • an article number
  • an article number followed by a dash to indicate all following
  • an article number followed by a dash followed by another article number

a successful response starts with a 224 response, then the reference info for all the matched messages, then a period on a line by itself ✨ with no argument, you get the info for the current article 💖 you need a news group selected earlier, or it's a 412 error 😭 no articles in the range means a 420 error 💀 and if you only have transfer permission, that's a 502 response 🔒

the output is the article number, followed by the contents of the References: line for that article 🎀 the field name itself isn't included 🙈

this gives you the same basic functionality as XHDR with "references" as the header argument 🦋

2.11.1 Responses

224 Overview information follows
412 No news group current selected
420 No article(s) selected
502 no permission

2.12 XTHREAD 🧵

XTHREAD [DBINIT|THREAD]

XTHREAD gets threading info in the format originally made for the TRN [6] news reader 🌈

XTHREAD DBINIT can be sent before you enter any groups, to see whether a thread database exists 👑 if it does, the database's byte order and version number come back as binary data 🤖

if you don't give a parameter, XTHREAD THREAD is assumed 💅

to use XTHREAD THREAD, a news group must have been selected earlier, or you get a 412 error 😭

if you only have permission to transfer articles, you get a 502 response 🔒 and a 503 response comes back if the threading files aren't available 💀

the trn-style thread format is explained in the TRN newsreader documentation 📖 and since newer TRN versions support the news overview (NOV) format, it is recommended that this extension become historic and no longer be used in current servers or future implementations 🍓 same story as TIN, bestie 💜

2.12.1 Responses

288 Binary data to follow
412 No newsgroup current selected
502 No permission
503 program error, function not performed

3. Other Extensions 🎀

3.1 AUTHINFO 🔐

okay so AUTHINFO is how a client tells a server who the user is 🫶 clients always have to give this info when the server asks for it 💖 but servers are not required to accept authentication info that the client volunteers 🙅 so clients have to be ready for servers that reject any authentication info they offer up unprompted 🌸

there are three forms of AUTHINFO in use ✨ there's the original version, an NNTP v2 revision called AUTHINFO SIMPLE, and a newer one called AUTHINFO GENERIC 🦋

3.1.1 Original AUTHINFO 🔐

AUTHINFO USER username
AUTHINFO PASS password

okay so the original AUTHINFO is the OG way to tell the server who you are: a plain username and password combo 💅 It first showed up in the UNIX reference implementation, so it's a certified classic ✨

When the server needs you to log in, it sends a 480 response asking for authorization. The client MUST enter AUTHINFO USER followed by the username. Once that's sent, the server caches the username and MAY send a 381 response asking for the password tied to it. If it does ask, the client MUST enter AUTHINFO PASS followed by the password, and then the server checks the authentication database to see if the combo is valid. If the combo is valid, or if no password is needed at all, the server returns a 281 response. Then the client SHOULD retry the original command that got the 480 response, and the command SHOULD then be processed by the server normally 🎀 If the combo is not valid, the server returns a 502 response.

Clients MUST provide authentication when the server asks for it 🫶 Some implementations will accept auth info at the very start of a session, but that was never the original plan 🙈 If a client tries to reauthenticate, the server MAY return a 482 response saying the new auth data got rejected. The 482 code also shows up when the AUTHINFO commands are sent in the wrong order, like two AUTHINFO USERs in a row, or AUTHINFO PASS before AUTHINFO USER 💀

All information is passed in cleartext. 🚨 Anyone watching the wire can read it, so this is not the place for your secrets, bestie.

When authentication succeeds, the server makes an email address for the client. It uses the username from AUTHINFO USER plus the hostname from a reverse lookup on the client's IP address. If that reverse lookup fails, the IP address in dotted-quad format is used instead 🦋 Once authenticated, the server SHALL generate a Sender: line using that email address if it doesn't match the client-supplied From: line. The server SHOULD also log the event, including the email address. This gives later statistics a way to link newsgroup references to unique entities, not necessarily by name 📊

3.1.1.1 Responses 🌸

281 Authentication accepted
381 More authentication information required
480 Authentication required
482 Authentication rejected
502 No permission

3.1.2 AUTHINFO SIMPLE 🧚

AUTHINFO SIMPLE
user password

this version of AUTHINFO was part of a proposed NNTP V2 specification. That spec was started in 1991 but never finished, though some servers and clients still use it 🫠 It's a refinement of the original AUTHINFO with the same basic functionality, but the command sequence is way simpler ✨

When authorization is required, the server sends a 450 response asking for it. The client MUST enter AUTHINFO SIMPLE. If the server will accept this form of authentication, it responds with a 350 response. The client MUST then send the username, followed by one or more space characters, followed by the password 💖 If it's accepted, the server returns a 250 response, and the client SHOULD retry the original command that got the 450 response. The command SHOULD then be processed by the server normally. If the combo is not valid, the server returns a 452 response.

Heads up: the response codes used here came from that proposed NNTP V2 spec and are violations of RFC 977. Implementing this command is NOT RECOMMENDED. If you need that functionality, use either or both of the other forms of AUTHINFO instead 🙅‍♀️

3.1.2.1 Responses 🎀

250 Authorization accepted
350 Continue with authorization sequence
450 Authorization required for this command
452 Authorization rejected

3.1.3 AUTHINFO GENERIC 🌈

AUTHINFO GENERIC authenticator arguments...

AUTHINFO GENERIC lets you identify yourself to the server using arbitrary authentication or identification protocols 🪄 The protocol you want is named by the authenticator parameter, and you can pass any number of parameters to that authenticator.

When authorization is required, the server sends a 480 response asking for it. The client SHOULD enter AUTHINFO GENERIC followed by the authenticator name, plus the arguments if there are any. The authenticator and arguments MUST NOT contain the sequence "..", so don't sneak that in 🙅‍♀️

The server tries to engage the server end authenticator, and similarly the client SHOULD engage the client end authenticator. The server end authenticator then starts authentication over the NNTP sockets (if that protocol makes sense for them), using the protocol named by the authenticator name. These authentication protocols aren't included in this document, but they're similar in structure to the ones referenced in RFC 1731 [8] for the IMAP-4 protocol 📚

If the server returns 501, that means the authenticator invocation was syntactically incorrect, or that AUTHINFO GENERIC isn't supported at all. In that case the client SHOULD retry using the AUTHINFO USER command 🔁

If the requested authenticator capability isn't found, the server returns the 503 response code 😬

If there's some other unspecified server program error, the server returns the 500 response code 💀

The authenticators talk back and forth using their protocol until they're done. If authentication succeeds, the server authenticator terminates with a 281, and the client can continue by reissuing the command that prompted the 380 🥹 If authentication fails, the server responds with a 502.

The client MUST provide authentication when the server requests it 🫶 The server MAY request authentication at any time, and it MAY request it more than once during a single session.

When the server authenticator finishes, it hands the server the email address of the user, and potentially what the user is allowed to access. The mechanism for that handoff is left undefined here 🤷‍♀️ Once authenticated, the server SHALL generate a Sender: line using the email address from the authenticator if it doesn't match the user-supplied From: line. The server SHOULD also log the event, including the user's authenticated email address (if it's available). Same reason as before: stats can then tie newsgroup references to unique entities, not necessarily by name 📊

Some implementations let you get a list of available authentication procedures by sending the server AUTHINFO GENERIC with no arguments. The server then returns a list of supported mechanisms, followed by a period on a line by itself 🍓

3.1.3.1 Responses 💜

281 Authentication succeeded
480 Authentication required
500 Command not understood
501 Command not supported
502 No permission
503 Program error, function not performed
nnn  authenticator-specific protocol.

3.2 DATE 🕰️

DATE

okay so the first NNTP working group discussed and proposed a syntax for this command. It lets clients ask the server what time it is from the server's point of view ⏰ When this was being discussed (1991-1992), the Network Time Protocol [9] (NTP) wasn't in wide use yet. Some people also worried that small systems might not be able to use NTP effectively 🙈

This command returns a one-line response with code 111, followed by the GMT date and time on the server in the form YYYYMMDDhhmmss 🌸

3.2.1 Responses 🎀

111 YYYYMMDDhhmmss

3.3 The WILDMAT format 🌟

The WILDMAT format was first developed by Rich Salz, based on the format the UNIX "find" command uses to describe file names. The goal was a uniform way to match patterns the same way the UNIX shell matches filenames 🐚 Patterns are implicitly anchored at the beginning and end of each string when they're tested for a match.

Besides a strict one-to-one match between the pattern and the source being checked, there are five pattern matching operations:

  1. The first is an asterisk (*), which matches any sequence of zero or more characters.
  2. The second is a question mark (?), which matches any single character.
  3. The third specifies a specific set of characters. The set is a list of characters, or a range of characters where the beginning and end of the range are separated by a minus (or dash) character, or any combination of lists and ranges. The dash can also be included in the set as a character if it's the beginning or end of the set. The set is enclosed in square brackets. The close square bracket (]) can be used in a set if it's the first character in the set 🧠
  4. The fourth operation is the logical not of the third operation. It's specified the same way as the third, with the addition of a caret character (^) at the beginning of the test string, just inside the open square bracket 🙃
  5. The final operation uses the backslash character to remove the special meaning from the open square bracket ([), the asterisk, the backslash, or the question mark. Two backslashes in a row evaluate to a backslash with no special meaning 🔙

3.3.1 Examples 🍭

a. [^]-] -- matches any single character other than a close square
            bracket or a minus sign/dash.

b. *bdc  -- matches any string that ends with the string "bdc"
            including the string "bdc" (without quotes).

c. [0-9a-zA-Z] -- matches any single printable alphanumeric ASCII
            character.

d. a??d  --  matches any four character string which begins
             with a and ends with d.

3.4 Additional Headers 💌

Lots of NNTP implementations add headers to Usenet articles when they get POSTed via NNTP 📨 This section talks about those. None of them conflict with RFC 1036, and Usenet transports that conform to RFC 1036 SHOULD pass them through unchanged 🫶

3.4.1 NNTP-Posting-Host 🖥️

The server adds this line to the header of a posted article. Its contents are either the IP address or the fully qualified domain name of the client host doing the posting. The fully qualified domain name SHOULD be determined by a reverse lookup in the DNS on the client's IP address 🔎 If the client's article already contains this line, the server removes it before the article gets accepted by the Usenet transport system.

This header gives some idea of the actual host doing the posting, as opposed to the Sender or From lines that might be in the article. It's not a fool-proof method, though. Reverse lookups in the DNS are vulnerable to certain kinds of spoofing, but those discussions are outside the scope of this document 🕵️‍♀️

3.4.2 X-Newsreader and others 📰

Clients add other lines too! Most of them show what type of newsreader software is doing the posting ✨

4.0 Common Implementation Issues 🛠️

Lots of NNTP implementations don't follow the specifications in RFC 977, which is kind of a whole vibe 😭 In this section, some common implementation issues get summarized 💅

4.1 The Response to the LIST command ✨

okay so RFC 977 says the fourth field of the "list of valid newsgroups associated information" you get back must be either 'y' or 'n', saying whether posting to that newsgroup is allowed ('y') or prohibited ('n'). 🎀 Most implementations just spit out the exact contents of the transport system's active newsgroup list, no cap. For more implementations, though, the fourth field usually has more values than just 'y' or 'n' 💅

4.2 The Required Headers in an Article and the POST command 🌸

RFC 977 notes in section 3.10.1 that articles presented "should include all required header lines." ngl, modern implementations only require From, Subject, and Newsgroups header lines and will supply the rest 🫶 Further, many implementers believe it's best for clients to generate as few headers as possible, since clients often don't format the other headers correctly 😭

This behaviour is consistent with both Bnews and Cnews, which would supply missing headers for articles submitted to them directly. It's giving teamwork 🤝

4.3 Article Numbering 🦋

RFC 977 doesn't directly address the rules for article numbers. However, the current practice is simple: article numbers are monotonically increasing, articles may disappear, and therefore the high and low water marks returned in a GROUP command should be treated as maximum minima, and minimum maxima, respectively. Lowkey a mind-bender, but it works 🧠✨

4.4 Availability of commands defined in RFC 977 🙈

Some implementations let administrators disable commands defined in RFC 977, and some have a set of commands disabled by default. This means client implementations can't depend on the availability of the disabled commands. That makes the client more complicated, and it doesn't encourage implementors to optimize commands that don't perform well. Not the vibe 💀

NEWNEWS is one of the commands that gets disabled the most 😤

4.5 The Distribution header and NEWNEWS 🌈

In section 12.4 of RFC 977, the optional distributions argument is described. According to RFC 977, this argument would limit the responses to articles that were in newsgroups whose prefixes matched the optional distributions argument.

Some implementations do this by matching the Distributions header in articles against the distribution argument. Others do the match against segments of the newsgroup's name. 👀

This variation is probably best explained by how the USENET article format evolved. When RFC 977 was specified, the newsgroup name defined how the group was distributed throughout USENET. RFC 1036 changed that convention. So, implementations that strictly follow RFC 977 match the newsgroup name prefix against the distribution argument and only display matches. Implementations that follow the intent of the command (as modified by the redefinition of the article format) match the Distributions header against the distribution argument and only display those matches. Main character energy, honestly 👑

5.0 Further Work 🔮

With NNTP still in use across the Internet, there's continued interest in creating an optimized transport protocol for server-to-server transfers and an optimized client protocol for client-to-server interactions. There's also considerable interest in building better mechanisms to provide audit information on which newsgroups are being read by which users. 📚

An IETF working group has been formed, and it's the hope of this author that these issues will be addressed in that forum 🌟

6.0 Security Considerations 🚨

bestie, this part is SERIOUS 😭 Use of AUTHINFO is optional. This command, as documented, has a number of security implications. In the original and simple forms, all passwords are passed in plaintext, and they could be discovered by various forms of network or system surveillance. The AUTHINFO GENERIC command has the potential for the same problems if a mechanism is used that also passes cleartext passwords. RFC 1731 [8] discusses these issues in greater detail. Protect your passwords like your whole social life depends on it 🔐💅

7.0 References 📖

[1] Kantor, B and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.

[2] Limoncelli, Tom, "Read This Before You Write a Newsreader", http://mars.superlink.net/tal/news-software-authors.html, June, 1996.

[3] Horton, M. and R. Adams, "Standard for interchange of USENET messages", RFC 1036, December 1987.

[4] Salz, Rich, Manual Page for wildmat(3) from the INN 1.4 distribution, UUNET Technologies, Revision 1.10, April, 1992.

[5] Robertson, Rob, "FAQ: Overview database / NOV General Information", ftp://ftp.uu.net/networking/news/nntp/inn/faq-nov.Z, January, 1995.

[6] Lea, Iain, "FAQ about the TIN newsreader", http://www.cs.unca.edu/~davidson/handouts/tinfaq.html

[7] Kappesser, Peter, "[news.software.readers] trn newsreader FAQ", 2 parts, ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/software/readers/%5Bnews.software.readers%5D_trn_newsreader_FAQ%2C_part_1%3A_Basics and ftp://rtfm.mit.edu/pub/usenet-by-hierarchy/news/software/readers/%5Bnews.software.readers%5D_trn_news-reader_FAQ%2C_part_2%3A_Advanced, February, 1995.

[8] Meyers, J., "IMAP4 Authentication Mechanisms", RFC 1731, December 1994.

[9] Mills, D., "Network Time Protocol (Version 3), Specification, Implementation and Analysis", RFC 1305, March 1992.

8.0 Notes 📝

DEC is a registered trademark of Compaq Computer Corporation. UNIX is a registered trademark of The Open Group. VMS is a registered trademark of Compaq Computer Corporation.

9.0 Acknowledgments 🫶

The author gratefully acknowledges the comments and additional information provided by the following individuals:

Wayne Davison <davison@armory.com>
Chris Lewis <clewis@bnr.ca>
Tom Limoncelli <tal@lucent.com>
Eric Schnoebelen <eric@egsner.cirr.com>
Rich Salz <rsalz@osf.org>

This work was precipitated by the work of various newsreader authors and newsserver authors, which includes those listed below:

Rick Adams    -- Original author of the NNTP extensions to the RN
                 newsreader and last maintainer of Bnews
Stan Barber   -- Original author of the NNTP extensions to the
                 newsreaders that are part of Bnews.
Geoff Collyer -- Original author of the OVERVIEW database proposal and
                 one of the original authors of CNEWS
Dan Curry     -- Original author of the xvnews newsreader
Wayne Davison -- Author of the first threading extensions to the
                 RN newsreader (commonly called TRN).
Geoff Huston  -- Original author of ANU NEWS
Phil Lapsey   -- Original author of the UNIX reference
                 implementation
Iain Lea      -- Original maintainer of the TIN newsreader
Chris Lewis   -- First known implementor of the AUTHINFO GENERIC
                 extension
Rich Salz     -- Original author of INN
Henry Spencer -- One of the original authors of CNEWS
Kim Storm     -- Original author of the NN newsreader

10.0 Author's Address 💌

Stan Barber

P.O. Box 300481

Houston, Texas, 77230

EMail: sob@academ.com

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. 🌈

📦 where this page comes from