NNRPD(8)

💅 nnrpd(8) 💅

okay bestie, buckle up — this is the manual page for nnrpd, and yes it's a whole personality. grab a matcha, we're doing this 🍓

---

✨ NAME ✨

nnrpd — the NNTP server for reader clients. that's it, that's the vibe. 👑

---

🦋 SYNOPSIS 🦋

nnrpd [-BDfnoSt] [-4 address] [-6 address] [-b address] [-c configfile]
[-i initial] [-I instance] [-p port] [-P prefork] [-r reason] [-s padding]

---

🌸 DESCRIPTION 🌸

So nnrpd is an NNTP server for newsreaders. literally what it says on the tin. it takes commands on its standard input and claps back on its standard output. normally innd(8) is the one that spins it up, with those descriptors glued to a remote client connection. but plot twist — nnrpd also supports running as a standalone daemon. main character energy fr.

Unlike innd(8), nnrpd supports all the NNTP commands for user-oriented reading and posting. all of them. and it uses the readers.conf file to decide who's even allowed to touch the Usenet database — it's giving bouncer at the club 🫶.

On exit, nnrpd reports usage statistics through syslog(3). little receipts, love that for us.

nnrpd gets run from innd (that's the default) or from inetd(8), xinetd(8), or some equivalent. and as often as not, it's also run as a daemon with the -D option, so it can serve TLS support on a dedicated port. versatile icon.

okay this next part is important so pay attention: nnrpd only reads its config files (readers.conf, inn.conf and inn-secrets.conf) when it is spawned. so you can never, ever change the behaviour of a client that's already connected — sorry, that ship has sailed. but because a new nnrpd process is spawned for every single connection, any changes to these configuration files are immediately effective for all new connections. slay. there's exactly one exception though: when nnrpd is run as a daemon with the -D option, any configuration changes in inn.conf won't take effect until nnrpd is restarted. one exception, and we're respecting it.

The inn.conf setting nnrpdflags can be used to pass any of the options below to instances of nnrpd that are spawned directly from innd. but heads up — many options only make sense when -D is used, so those ones should not be used with nnrpdflags. see also the discussion of nnrpdflags in inn.conf(5).

When nnrpdloadlimit in inn.conf is not "0", it will also reject connections if the load average is greater than that value (typically "16"). so it's got a whole bouncer-plus-capacity-check situation going on. nnrpd can also prevent high-volume posters from abusing your resources — see the discussion of exponential backoff in inn.conf(5). we love a server with boundaries 💅

nnrpd injects articles into the local server running innd through a UNIX domain socket, or an INET domain socket if that's not supported. if another server should be used for injection, you can set it with the nnrpdposthost parameter in inn.conf. and in case authentication credentials are requested during the injection, nnrpd will use the passwd.nntp file in pathetc. iykyk.

---

🎀 OPTIONS 🎀

okay here's the whole flag lineup, no skips, no cuts, we're doing all of them:

• -4 address — tells nnrpd to bind to the specified IPv4 address when it's started as a standalone daemon using the -D flag. this has to be a valid IPv4 address belonging to an interface of the local host. it can also be "0.0.0.0", which means bind to all addresses — and fun fact, that's the default.
• -6 address — same situation but for IPv6: tells nnrpd to bind to the specified IPv6 address when started as a standalone daemon using the -D flag. it has to be a valid IPv6 address belonging to an interface of the local host. it can also be "::0", which says bind to all IPv6 addresses.

by default, nnrpd in daemon mode listens to both IPv4 and IPv6 addresses. with this option, it will listen only to the specified IPv6 addresses. however, on some systems, a value of "::0" will cause it to listen to all IPv4 addresses as well. so like… read your system's vibes on that one 😭

• -b address — similar to the -4 flag. -b is kept for backward compatibility. legacy queen, still valid 💜
• -B — if specified, nnrpd will report login attempts to blocklistd(8) for automatic blocking after a number of failed attempts. to use this flag, the blocklist library must have been found at configure time, or --with-blocklist specified at configure time. for more information, see "BLOCKLISTD SUPPORT" below. bye to the brute-forcers 🚪
• -c configfile — by default, nnrpd reads the readers.conf configuration file to figure out how to authenticate connections. the -c flag specifies an alternate file for this purpose. if the file name isn't fully qualified, it's taken to be relative to pathetc in inn.conf. (this is useful to have several instances of nnrpd running on different ports or IP addresses with different settings — a whole little friend group of servers 🫶)
• -D — if specified, this parameter causes nnrpd to operate as a daemon. that is, it detaches itself and runs in the background, forking a process for every connection. by default, nnrpd listens on the NNTP port (119), so either innd(8) has to be started on another port or the -p parameter used. note that with this parameter, nnrpd continues running until killed — which means it reads inn.conf once on startup and never again until restarted. nnrpd should therefore be restarted if inn.conf is changed. no cap, just restart it.

when started in daemon mode, nnrpd will write its PID into a file in the pathrun directory. the file will be named nnrpd.pid if nnrpd listens on port 119 (default), or nnrpd-%d.pid, where "%d" is replaced with the port that nnrpd is configured to listen on (the -p option is given and its argument is not "119").

you may also want to use -s when running nnrpd as a daemon. friendly suggestion ✨

• -f — if specified, nnrpd does not detach itself and runs in the foreground when started as a standalone daemon using the -D flag. it's giving "i'm staying right here where you can see me" 🙈
• -i initial — specify an initial command to nnrpd. when used, initial is taken as if it were the first command received by nnrpd. after having responded, nnrpd will close the connection. one command and then it's out, iconic.
• -I instance — if specified, instance is used as an additional static portion within Message-IDs generated by nnrpd, when virtualhost is set in access groups in readers.conf. typically this option would be used where a cluster of machines exist with the same virtual hostname and must be disambiguated during posts. disambiguate, bestie 💅
• -n — the -n flag turns off resolution of IP addresses to names. if you only use IP-based restrictions in readers.conf and can handle IP addresses in your logs, using this flag may result in some additional speed. free speed, we love a shortcut 🏃‍♀️
• -o — the -o flag causes all articles to be spooled instead of sending them to innd(8). rnews with the -U flag should be invoked from cron on a regular basis to take care of these articles. this flag is useful if innd is accepting articles and nnrpd is started standalone or using inetd(8). team spool 🍓
• -p port — tells nnrpd to listen on port when started as a standalone daemon using the -D flag. pick your port, live your truth.
• -P prefork — tells nnrpd to prefork prefork children awaiting connections when started as a standalone daemon using the -D flag. build the squad in advance 🧚
• -r reason — if the -r flag is used, then nnrpd will reject the incoming connection giving reason as the text. this flag is used by innd(8) when it is paused or throttled. reason should be encoded in UTF-8. polite rejection, correct encoding. periodt.
• -s padding — as each command is received from a client, nnrpd tries to change its "argv" array containing the process title so that commands like ps(1) will print out the hostname of the connected client and the command being executed. to get a full display, the -s flag may be used with a long string as its argument, which will be overwritten when nnrpd changes its title.

when innd spawns nnrpd, this flag is used with an argument made of 48 spaces. forty-eight. iconic padding 💀

• -S — if specified, nnrpd will start a negotiation for a TLS session as soon as connected. to use this flag, the OpenSSL SSL and crypto libraries must have been found at configure time, or --with-openssl specified at configure time. for more information on running nnrpd with TLS support, see "TLS SUPPORT". secure connection speedrun 🔥
• -t — if the -t flag is used, then all client commands and initial responses will be traced by reporting them in syslog. this flag is set by innd(8) under the control of the ctlinnd(8) "trace" command, and is toggled upon receipt of a SIGHUP; see signal(2). surveillance but make it consensual 🌈

---

okay that's the flags done — and there's still more coming, so don't go anywhere, bestie 🦋

✨ TLS SUPPORT ✨

okay so bestie, here's the TLS tea ☕️ If INN is built with --with-openssl or if the OpenSSL SSL and crypto libraries are found at configure time, nnrpd will support news reading over TLS (also known as SSL). Simple as that 💅

For clients that use the STARTTLS command, no special configuration is needed beyond creating a TLS/SSL certificate for the server. You should do this in exactly the same way that you would generate a certificate for a web server. iconic behavior honestly 🫶

If you're happy with a self-signed certificate (which will generate warnings with some news reader clients), you can create and install one in the default path by running make cert after make install when installing INN, or by running the following commands:

umask 077
openssl req -new -x509 -nodes -out <pathetc>/cert.pem \
    -days 366 -keyout <pathetc>/key.pem
chown news:news <pathetc>/cert.pem
chmod 640 <pathetc>/cert.pem
chown news:news <pathetc>/key.pem
chmod 600 <pathetc>/key.pem

Replace the paths with something appropriate to your INN installation. This will create a self-signed certificate that will expire in a year. The openssl program will ask you a variety of questions about your organization. Enter the fully qualified domain name of your news service (either the server canonical name or a dedicated alias for the news service) as the name the certificate is for. yes, that's the moment to be yourself but like, with your actual server name 😌

You then have to set these inn.conf parameters with the right paths:

tlscapath:      <pathetc>
tlscertfile:    <pathetc>/cert.pem
tlskeyfile:     <pathetc>/key.pem

If you want to use a complete certificate chain, you can directly put it in tlscertfile (like Apache's SSLCertificateFile directive). Alternately, you can put a single certificate in tlscertfile and use tlscafile for additional certificates needed to complete the chain, like a separate authority root certificate. chain game: strong 💪

More concretely, when using Let's Encrypt certificates, Certbot's files can be installed as follows:

tlscapath:      /etc/letsencrypt/live/news.server.com
tlscertfile:    /etc/letsencrypt/live/news.server.com/fullchain.pem
tlskeyfile:     /etc/letsencrypt/live/news.server.com/privkey.pem

or:

tlscapath:      /etc/letsencrypt/live/news.server.com
tlscafile:      /etc/letsencrypt/live/news.server.com/chain.pem
tlscertfile:    /etc/letsencrypt/live/news.server.com/cert.pem
tlskeyfile:     /etc/letsencrypt/live/news.server.com/privkey.pem

Make sure that the permission rights are properly set so that the news user or the news group can read these directories and files (typically, he should access /etc/letsencrypt/live/news.server.com and /etc/letsencrypt/archive/news.server.com where the real keys are located, and the private key should not be world-readable). lock that private key down, bestie 🔐 no casual scrolling for strangers.

If you prefer to point to files outside the directory of Let's Encrypt, you may add a post-renewal hook for Let's Encrypt to copy the generated files to another location, and give them the expected rights. lowkey a little choreography for your certs 🩰

There are two common ways for a news client to negotiate a TLS connection: either via the use of a dedicated port (usually 563) on which TLS is immediately negotiated upon connection, or via the now discouraged way (per RFC 8143) to use the STARTTLS command on the usual NNTP port (119) to dynamically upgrade from unencrypted to TLS-protected traffic during an NNTP session. innd does not, however, know how to listen for connections to that separate port (563). You will therefore need to arrange for nnrpd to listen on that port through some other means. This can be done with the -D flag along with "-p 563" and put into your init scripts:

su news -s /bin/sh -c '<pathbin>/nnrpd -D -p 563 -S'

but the easiest way is probably to add a line like:

nntps stream tcp nowait news <pathbin>/nnrpd nnrpd -S

to /etc/inetd.conf or the equivalent on your system and let inetd run nnrpd. (Change the path to nnrpd to match your installation.) You may need to replace "nntps" with "563" if "nntps" isn't defined in /etc/services on your system. You may also want to use the lowercase -s flag with a long string as its argument to see more information about incoming connections in ps(1) output. cute little detective mode for your sockets 🔍

Optionally, you may set the tlsciphers, tlsciphers13, tlscompression, tlseccurve, tlspreferserverciphers, and tlsprotocols parameters in inn.conf to fine-tune the behaviour of the TLS/SSL negotiation whenever a new attack on the TLS protocol or some supported cipher suite is discovered. stay tuned, stay fine-tuned 💫

---

🔥 BLOCKLISTD SUPPORT 🔥

blocklistd(8) is a FreeBSD/NetBSD daemon for preventing brute force attacks by blocking attackers after a number of failed login attempts. When nnrpd is built with blocklistd support, it will report login attempts to the blocklistd daemon for potential blocking. goodbye to the little password-guessing goblins 👋😭

Adding the configuration below to /etc/blocklistd.conf under the "[local]" section, assuming nnrpd is listening on port 563, would lead to attackers being blocked for 10 minutes after 5 failed login attempts. love that for us 💅

# adr/mask:port type    proto owner name nfail disable
563             stream  *     *     *    5     10m

See the blocklistd(8) documentation for more information. go read the lore bestie 📚

---

🌈 PROTOCOL DIFFERENCES 🌈

nnrpd implements the NNTP commands defined in RFC 3977 (NNTP), RFC 4642 updated by RFC 8143 (TLS/NNTP), RFC 4643 (NNTP authentication), RFC 6048 (NNTP LIST additions) and RFC 8054 (NNTP compression) with the following differences:

1. The XGTITLE [wildmat] command is provided. This extension is used by ANU-News and documented in RFC 2980. It returns a "282" reply code, followed by a one-line description of all newsgroups that match the pattern. The default is the current group.

Note that LIST NEWSGROUPS should be used instead of XGTITLE. okay so old-school icon, but we're using the newer one now 🫶

2. The XHDR header [message-ID|range] command is implemented. It returns a "221" reply code, followed by specific header fields for the specified range; the default is to return the data for the current article. See RFC 2980.

Note that HDR should be used instead of XHDR. respectfully, use the newer one bestie ✨

3. The XOVER [range] command is provided. It returns a "224" reply code, followed by the overview data for the specified range; the default is to return the data for the current article. See RFC 2980.

Note that OVER should be used instead of XOVER. same energy, newer name 💅

4. A new command, XPAT header message-ID|range pattern [pattern ...], is provided. The first argument is the case-insensitive name of the header field to be searched. The second argument is either an article range or a single message-ID, as specified in RFC 2980. The third argument is a uwildmat-style pattern; if there are additional arguments, they are joined together separated by a single space to form the complete pattern. This command is similar to the XHDR command. It returns a "221" response code, followed by the text response of all article numbers that match the pattern. pattern-matching main character energy 🔍💖
5. A newsgroup name is case-sensitive for nnrpd. caps matter, no cap 🧢
6. If IHAVE has been advertised, it will not necessarily be advertised for the entire session (contrary to section 3.4.1 of RFC 3977). nnrpd only advertises the IHAVE capability when it is really available. honesty is the policy fr fr 💯
7. nnrpd allows a wider syntax for wildmats and ranges (especially - and -article-number). flexible queen 🌸
8. When keyword generation is used, an experimental feature enabled with the keywords parameter in inn.conf, "Keywords:full" is advertised in LIST OVERVIEW.FMT even though overview information is computed and does not necessarily come from Keywords header fields. experimental but make it cute 🧪💫

---

🎀 HISTORY 🎀

Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Overview support added by Rob Robertston <rob@violet.berkeley.edu> and Rich in January, 1993. Exponential backoff (for posting) added by Dave Hayes in Febuary 1998. yes, "Febuary" is exactly how it's written here — we keep the lore intact 😭💀

---

🦋 SEE ALSO 🦋

• blocklistd(8)
• ctlinnd(8)
• innd(8)
• inn.conf(5)
• inn-secrets.conf(5)
• libinn_uwildmat(3)
• nnrpd.track(5)
• passwd.nntp(5)
• readers.conf(5)
• signal(2)

---

okay that's the whole NNRPD(8) page, bestie 🫶 this lil masterpiece is from INN 2.7.4, dated 2026-06-12. now go read some news and slay 💅✨