Provided by: inn2_2.7.3-1_amd64 bug

NAME

       nnrpd - NNTP server for reader clients

SYNOPSIS

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

DESCRIPTION

       nnrpd is an NNTP server for newsreaders.  It accepts commands on its standard input and responds on its
       standard output.  It is normally invoked by innd(8) with those descriptors attached to a remote client
       connection.  nnrpd also supports running as a standalone daemon.

       Unlike innd(8), nnrpd supports all NNTP commands for user-oriented reading and posting.  nnrpd uses the
       readers.conf file to control who is authorized to access the Usenet database.

       On exit, nnrpd will report usage statistics through syslog(3).

       nnrpd is run from innd (the default) or from inetd(8), xinetd(8), or some equivalent.  As often as not,
       it is also run as a daemon, with the -D option, to provide TLS support on a dedicated port.

       nnrpd only reads config files (readers.conf, inn.conf and inn-secrets.conf) when it is spawned.  You can
       therefore never change the behaviour of a client that's already connected.  As a new nnrpd process is
       spawned for every connection, any changes to these configuration files will be immediately effective for
       all new connections.  There's only one exception: 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.

       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.  Many options only make sense when -D is used, so these options 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").  nnrpd can also prevent high-volume posters from abusing your
       resources.  See the discussion of exponential backoff in inn.conf(5).

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

OPTIONS

       -4 address
           The  -4  parameter instructs nnrpd to bind to the specified IPv4 address when 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", saying to bind to all addresses (this is the default).

       -6 address
           The -6 parameter instructs nnrpd to bind to the specified IPv6 address when started as  a  standalone
           daemon using the -D flag.  This has to be a valid IPv6 address belonging to an interface of the local
           host.  It can also be "::0", saying to 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.  On some systems however, a value of "::0" will cause it
           to listen to all IPv4 addresses as well.

       -b address
           Similar to the -4 flag.  -b is kept for backwards compatibility.

       -B  If specified, nnrpd will report login attempts to blacklistd(8) for automatic blocking after a number
           of failed attempts.  To use this flag, the blacklist library must have been found at configure  time,
           or  --with-blacklist  specified  at  configure  time.  For more information, see "BLACKLISTD SUPPORT"
           below.

       -c configfile
           By default, nnrpd reads  the  readers.conf  configuration  file  to  determine  how  to  authenticate
           connections.  The -c flag specifies an alternate file for this purpose.  If the file name isn't fully
           qualified,  it  is  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.)

       -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.  This means that it reads inn.conf
           once on startup and never again until restarted.  nnrpd should therefore be restarted if inn.conf  is
           changed.

           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 (-p option is given and its argument  is
           not "119").

           You may also want to use -s when running nnrpd as a daemon.

       -f  If  specified,  nnrpd  does not detach itself and runs in the foreground when started as a standalone
           daemon using the -D flag.

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

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

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

       -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).

       -p port
           The  -p  parameter instructs nnrpd to listen on port when started as a standalone daemon using the -D
           flag.

       -P prefork
           The -P parameter instructs nnrpd to prefork prefork children awaiting connections when started  as  a
           standalone daemon using the -D flag.

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

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

       -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".

       -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).

TLS SUPPORT

       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).  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.

       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.

       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.

       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).

       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.

       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.

       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.

BLACKLISTD SUPPORT

       blacklistd(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 blacklistd support, it will report login
       attempts to the blacklistd daemon for potential blocking.

       Adding the configuration below to /etc/blacklistd.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.

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

       See the blacklistd(8) documentation for more information.

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.

       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.

       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.

       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.

       5.  A newsgroup name is case-sensitive for nnrpd.

       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.

       7.  nnrpd allows a wider syntax for wildmats and ranges (especially "-" and "-article-number").

       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.

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.

SEE ALSO

       blacklistd(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).

INN 2.7.3                                          2025-05-19                                           NNRPD(8)