INN.CONF(5) | InterNetNews Documentation | INN.CONF(5) |
inn.conf - Configuration data for InterNetNews programs
inn.conf in pathetc is the primary general configuration file for all InterNetNews programs. Settings which control the general operation of various programs, as well as the paths to all portions of the news installation, are found here. The INNCONF environment variable, if set, specifies an alternate path to inn.conf.
This file is intended to be fairly static. Any changes made to it will generally not affect any running programs until they restart. Unlike nearly every other configuration file, inn.conf cannot be reloaded dynamically using ctlinnd(8); innd(8) must be stopped and restarted for relevant changes to inn.conf to take effect ("ctlinnd xexec innd" is the fastest way to do this.)
Blank lines and lines starting with a number sign ("#") are ignored. All other lines specify parameters, and should be of the following form:
<name>: <value>
(Any amount of whitespace can be put after the colon and is optional.) If the value contains embedded whitespace or any of the characters "[]<>{}"\:;", it must be enclosed in double quotes (""). A backslash ("\") can be used to escape quotes and backslashes inside double quotes. <name> is case-sensitive; "server" is not the same as "Server" or "SERVER". (inn.conf parameters are generally all in lowercase.)
If <name> occurs more than once in the file, the first value is used. Some parameters specified in the file may be overridden by environment variables. Most parameters have default values if not specified in inn.conf; those defaults are noted in the description of each parameter.
Many parameters take a boolean value. For all such parameters, the value may be specified as "true", "yes", or "on" to turn it on and may be any of "false", "no", or "off" to turn it off. The case of these values is significant.
This documentation is extremely long and organized as a reference manual rather than as a tutorial. If this is your first exposure to INN and these parameters, it would be better to start by reading other man pages and referring to this one only when an inn.conf parameter is explicitly mentioned. Those parameters which need to be changed when setting up a new server are discussed in INSTALL.
These parameters are used by a wide variety of different components of INN.
This parameter is not meant to be used to affect the right-hand side of autogenerated Message-IDs; you have to directly use domain in readers.conf(5) instead, for backwards-compatible reasons. (The name of this parameter in readers.conf will likely be changed in a future major release to disambiguate its use.)
Note that these flags are only used when innd is started from rc.news or nntpsend.
The string %s, if present, will be replaced by the expected recipient(s) like the e-mail address of the moderator or of a remote list. It's strongly recommended for this command to end with %s on the command line rather than, when not present, use the addresses in the To and Cc header fields of the message, since the latter approach allows the news server to be abused as a mechanism to send mail to arbitrary addresses and will result in unexpected behaviour. There is no default value for this parameter; it must be set in inn.conf or a fatal error message will be logged via syslog.
For most systems, "/usr/lib/sendmail -oi -oem %s" (adjusted for the correct path to sendmail, and between double quotes) is a good choice.
To improve deliverability of sent mails, especially moderated group submissions, you are encouraged to install a modern and full-featured MTA like Postfix instead of a frugal MTA like Nullmailer. You'll then be able to configure bounces and benefit from DSN (Delivery Status Notifications). Useful flags to add, if your mta program supports them, are "-N failure" (to only return a DSN on failure, not delay), "-F 'Newsmaster'" (to set the full name of the notification), "-fnewsmaster@server.com" (to set the envelope sender address), and "-opnobodyreturn" (a privacy option to only return headers in the DSN). Feel free to add any other options you think appropriate.
The main purpose of the path identity is to avoid being proposed by your peers articles that already contain your path identity in their Path header fields.
In case you are running several internal news servers, you may want to also set pathcluster so as to define the primary path identity to advertise to your peers for their use in correctly identifying your news servers and adding the right path diagnostic (see Section 3.2.1 of RFC 5537 for more details about path diagnostics).
actsync, getlist, inews, and nntpget also use this value as the default server to connect to. In the latter cases, the value of the NNTPSERVER environment variable, if it exists, overrides this. The default value is unset.
rnews uses this value as a fallback when nnrpdposthost is not set, and there's no localhost server.
syntaxchecks: [ no-laxmid ]
The last occurrence of a given value takes precedence, that is to say if "no-laxmid laxmid" is listed, laxmid takes precedence.
Only one check can currently be enabled/disabled:
These parameters govern incoming and outgoing feeds: what size of articles are accepted, what filtering and verification is performed on them, whether articles in groups not carried by the server are still stored and propagated, and other similar settings.
In order to disable that check on date, you can set this parameter to 0.
The number on the "/remember/" line in expire.ctl should probably be one more than that number in order to take into account articles whose posting date is one day into the future.
This parameter has no effect when systemd socket activation is used.
Note that you will generally need to put double quotes ("") around this value if you set it, since IPv6 addresses contain colons.
This parameter has no effect when systemd socket activation is used.
Unless rejected by the use of a filter hook, innd always accepts and propagates cancel articles and supersede requests. However, actually processing such articles on the local news server depends on this parameter which can take the following values:
This is the default value if innd knows how to authenticate cancels (that is to say if INN was built with Cancel-Lock support). Otherwise, the behaviour will be the same as "none".
This is the default value if innd does not know how to authenticate cancels (that is to say if INN was not built with Cancel-Lock support) as it has no means to ensure that these withdrawal requests are legitimate.
This setting is ignored unless the timecaf storage method is used.
The main purpose of this parameter is when there is some other path identity that you want to add to the Path header field of every article passing through your news server(s) for some reason, maybe because you used to have some other path identity and you have peers that are configured to not send you articles that have already passed through that entity, and you can't get them to update to your current path identity for some reason.
The main purpose of this parameter is to set the name that you are using to identify yourself to peers (i.e. the path identity they should expect to see from you) in the cases where that doesn't match the main path identity pathhost for this news server. (The most common case where that happens is when you have multiple news servers that you want to present as a "united front" to the outside world and identify as the same virtual server, but you still want distinct path identities so those servers can internally feed each other. Also, even without internal feeds, pathcluster could be set to an organization name if the organization has multiple news servers.)
The logtrash parameter specifies whether such articles should be logged as posted to unwanted newsgroups in the news log file.
The following parameter affect the history database.
These parameters affect how articles are stored on disk.
extraoverviewadvertised: [ Path Newsgroups ]
it implies that nnrpd will advertise "Path:full" and "Newsgroups:full" as the ninth and tenth fields in response to LIST OVERVIEW.FMT and that these two header field bodies will be stored in the overview database for each new article. It may be a useful configuration to have as some news readers do article scoring with rules based on these two header fields. Having them in the overview database permits being faster at scoring for these readers, without having to separately request them, but on the other hand these additional fields are also present in overview requests of all the other readers, which slightly slows their reading.
The default value is an empty list (no additional fields are stored). Owing to optimizations when innd parses the articles it receives, it is possible that all the values in the list are not recognized by innd as standard header field names. In such cases, innd will log an error in news.err at startup and the unrecognized fields will be discarded. Moreover, the deprecated "Bytes" and "Lines" header fields, already present in the standard overview fields as metadata items, cannot be added.
You should advertise only fields for which the overview database is consistent, that is to say it records the content or absence of these fields for all articles, including those already existing in the news spool. Consequently, if you decide to add or remove a field from your overview database, you should either modify extraoverviewadvertised and rebuild your overview database with makehistory(8) after removing all existing overview files, or implement a transition period by first using extraoverviewhidden as described below.
Use of a transition period can accommodate most overview reconfigurations, but certain drastic changes may still require a complete overview rebuild.
If for instance you want to store the content of the Injection-Info header field body in addition to the fields already stored above, you should use:
extraoverviewadvertised: [ Path Newsgroups ] extraoverviewhidden: [ Injection-Info ]
This way, "Injection-Info:full" will not be advertised by nnrpd but will be stored for each new article. Once you know that all articles in your overview database record the content or absence of that new field (if expire.ctl(5) is parameterized so that all your articles expire within 30 days, you can assume the database is in such a state after 30 days -- however, note that time to expiration can be unpredictable with CNFS and you then have to use "cnfsstat -a" for checking on when buffers have rolled over), you should put:
extraoverviewadvertised: [ Path Newsgroups Injection-Info ] extraoverviewhidden: [ ]
The "Injection-Info" value must be added at the end of the list because order matters and fields mentioned in extraoverviewhidden are generated after those mentioned in extraoverviewadvertised. nnrpd will now advertise "Injection-Info:full" in response to the LIST OVERVIEW.FMT command ("full" indicates that the header field name appears followed by its value).
Now suppose you want to remove the content of the Newsgroups header field from the overview. As order matters, the overview database will no longer be consistent for the Injection-Info header field. Therefore, you need to specify:
extraoverviewadvertised: [ Path ] extraoverviewhidden: [ Injection-Info ]
And once overview data is accurate for all articles, you should use:
extraoverviewadvertised: [ Path Injection-Info ] extraoverviewhidden: [ ]
Note that you have to restart nnrpd if it runs as a daemon whenever you change the value of extraoverviewadvertised; a mere "ctlinnd xexec innd" is not enough.
The default value is an empty list (no additional fields are stored). Owing to optimizations when innd parses the articles it receives, it is possible that all the values in the list are not recognized by innd as standard header field names. In such cases, innd will log an error in news.err at startup and the unrecognized fields will be discarded. Moreover, the deprecated "Bytes" and "Lines" header fields, already present in the standard overview fields as metadata items, cannot be added.
This setting is ignored unless ovmethod is set to "tradindexed".
If the tradspool article storage method is used, storeonxref must be true.
These parameters affect the behavior of INN for readers. Most of them are used by nnrpd(8). There are some special sets of settings that are broken out separately after the initial alphabetized list.
You may also want to see the groupexactcount parameter in readers.conf(5) which controls the computing of the estimated article count returned in NNTP commands (GROUP, LIST COUNTS, LISTGROUP).
INN has optional support for generating keyword information automatically from article body text and putting that information in overview for the use of clients that know to look for it (HDR, OVER and XPAT commands). The following parameters control that feature, which should be considered experimental. Its very simple text tokenization works only on plain-text ASCII articles, and totally lacks of understanding of anything other than English. Articles encoded in Base64 or Quoted-Printable, having a MIME structure, or farther afield from English will have garbage in the generated Keywords header field.
This feature may be too slow if you're taking a substantial feed, and probably will not be useful for the average news reader; enabling this is not recommended unless you have some specific intention to take advantage of it.
If an article already contains a Keywords header field, no keyword generation is done and the original Keywords header field is kept untouched.
In order to use this feature, the regex library should be available and INN configured with the --enable-keywords flag. Otherwise, no keywords will be generated, even though this boolean value is set to true. You also have to add the Keywords header field into the overview with extraoverviewadvertised or extraoverviewhidden.
These parameters are only used by nnrpd(8), inews(1), and other programs that accept or generate postings. There are some special sets of settings that are broken out separately after the initial alphabetized list.
Note that no Injection-Date header fields will be added to local posts already containing both a Message-ID header field and a Date header field. This is done in conformance with standards, to help minimize the possibility of a loop in e-mail gatewaying and ensure that a newly injected article is not treated as a new, separate article in case of multiple injection of the same article to different injecting agents.
When this parameter is set to true, an FQDN (obtained by reverse lookup of the client IP address or, if unknown, the IP address itself) of the client is also added to the Path header field body, after the "!.POSTED" diagnostic.
nnrpd(8) has support for controlling high-volume posters via an exponential backoff algorithm, as configured by the following parameters.
Exponential posting backoff works as follows: news clients are indexed by IP address (or username, see backoffauth below). Each time a post is received from an IP address, the time of posting is stored (along with the previous sleep time, see below). After a configurable number of posts in a configurable period of time, nnrpd(8) will begin to sleep for increasing periods of time before actually posting anything (posting backoff is therefore activated). Posts will still be accepted, but at an increasingly reduced rate.
After backoff has been activated, the length of time to sleep is computed based on the difference in time between the last posting and the current posting. If this difference is less than backoffpostfast, the new sleep time will be 1 + (previous sleep time * backoffk). If this difference is less than backoffpostslow but greater than backoffpostfast, then the new sleep time will equal the previous sleep time. If this difference is greater than backoffpostslow, the new sleep time is zero and posting backoff is deactivated for this poster. (Note that this does not mean posting backoff cannot be reactivated later in the session.)
Exponential posting backoff will not be enabled unless backoffdb is set and backoffpostfast and backoffpostslow are set to something other than their default values.
Here are the parameters that control exponential posting backoff:
Here are the parameters used by nnrpd(8) to provide TLS/SSL support.
The parameters related to certificates are:
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).
This file must only be readable by the news user or nnrpd will refuse to use it.
Finally, here are the parameters that can be used to tighten the level of security provided by TLS/SSL in case new attacks exploitable in NNTP on the TLS protocol or some supported cipher suite are discovered:
Note that a separate cipher suite configuration parameter is needed for TLS 1.3 because TLS 1.3 cipher suites are not compatible with TLS 1.2, and vice-versa. In order to avoid issues where legacy TLS 1.2 cipher suite configuration configured in the tlsciphers parameter would inadvertently disable all TLS 1.3 cipher suites, the inn.conf configuration has been separated out.
Note that enabling TLS/SSL-level compression will be possible only if the OpenSSL library INN has been built with, supports that feature.
The default is unset, which means an appropriate curve is auto-selected (if your OpenSSL version is at least 1.0.2 or you are using LibreSSL) or the NIST P-256 curve is used.
This option is only effective if your OpenSSL version has ECDH support.
tlsprotocols: [ TLSv1.2 TLSv1.3 ]
Note that the listed protocols will be enabled only if the OpenSSL library INN has been built with, supports them. In case OpenSSL supports protocols more recent than TLSv1.3, they will be automatically enabled (which anyway is fine regarding security, as newer protocols are supposed to be more secure).
"SSLv2" was formally deprecated by RFC 6176 in 2011, "SSLv3" by RFC 7568 in 2015, "TLSv1.0" and "TLSv1.1" by RFC 8996 in 2021.
These parameters control the behavior of innwatch(8), the program that monitors INN and informs the news administrator if anything goes wrong with it.
These parameters control what information INN logs.
The following parameters can be modified to tune the low-level operation of INN. In general, you shouldn't need to modify any of them except possibly rlimitnofile unless the server is having difficulty.
Here is a very minimalist example that only sets those parameters that are required.
mta: "/usr/lib/sendmail -oi -oem %s" ovmethod: tradindexed pathhost: news.example.com pathnews: /usr/local/news hismethod: hisv6
For a more comprehensive example, see the sample inn.conf distributed with INN and installed as a starting point; it contains all of the default values for reference.
Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews and since modified, updated, and reorganized by innumerable other people.
inews(1), innd(8), innwatch(8), libinn_dbz(3), libinn_uwildmat(3), makehistory(8), nnrpd(8), rnews(1).
Nearly every program in INN uses this file to one degree or another. The above are just the major and most frequently mentioned ones.
2023-09-06 | INN 2.7.1 |