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.
Note that these flags are only used when innd is started from rc.news or nntpsend.
For most systems, "/usr/lib/sendmail -oi -oem %s" (adjusted for the correct path to sendmail, and between double quotes) is a good choice.
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.
This setting is ignored unless the timecaf storage method is used.
Note that the Path: header reads right to left, so appended means inserted at the leftmost side of the Path: header.
This is a somewhat messy, inefficient, and inexact way of refusing spam cancels. A much better way is to ask all of your upstream peers to not send to you any articles with "cyberspam" in the Path: header (usually accomplished by having them mark "cyberspam" as an alias for your machine in their feed configuration). The filtering enabled by this parameter is hard-coded; general filtering of message IDs can be done via the embedded filtering support.
Note that RFC 5537 (USEPRO) mentions that "cancel control messages are not required to contain From: and Sender: header fields matching the target message. This requirement only encouraged cancel issuers to conceal their identity and provided no security". This check is therefore not done as it is extremely easy to spoof.
In order not to actually process any cancel or supersedes messages, you can start innd with the -C flag, or add this flag to the innflags parameter.
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 Injection-Info ]
it implies that nnrpd will advertise "Path:full" and "Injection-Info:full" as the ninth and tenth fields in response to LIST OVERVIEW.FMT and that these two headers will be stored in the overview database for each new article.
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 headers. In such cases, innd will log an error in news.err at startup and the unrecognized fields will be discarded.
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 To: header in addition to the fields already stored above, you should use:
extraoverviewadvertised: [ Path Injection-Info ] extraoverviewhidden: [ To ]
This way, "To: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 parametered 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 Injection-Info To ] extraoverviewhidden: [ ]
The "To" 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 "To:full" in response to the LIST OVERVIEW.FMT command ("full" indicates that the header appears followed by its value).
Now suppose you want to remove the content of the Injection-Info: header from the overview. As order matters, the overview database will no longer be consistent for the To: header. Therefore, you need to specify:
extraoverviewadvertised: [ Path ] extraoverviewhidden: [ To ]
And once overview data is accurate for all articles, you should use:
extraoverviewadvertised: [ Path To ] 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 headers. In such cases, innd will log an error in news.err at startup and the unrecognized fields will be discarded.
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.
Note that the two parameters nnrpperlauth and nnrppythonauth are now obsolete; see "Changes to Perl Authentication Support for nnrpd" in doc/hook-perl and "Changes to Python Authentication and Access Control Support for nnrpd" in doc/hook-python for more information.
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.
This 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, no keyword generation is done and the original Keywords: header 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 integration of the Keywords: header 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, 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:
Note that unlike Apache's SSLCertificateFile directive, tlscertfile should not contain a concatenation of certificates. Instead, if you have a certificate authority root certificate, set tlscafile to its path.
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 the NIST P-256 curve is used.
This option is only effective if your OpenSSL version has ECDH support.
tlsprotocols: [ TLSv1 TLSv1.1 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).
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.
$Id: inn.conf.pod 10523 2021-01-17 21:52:00Z iulius $
inews(1), innd(8), innwatch(8), 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.
2021-01-21 | INN 2.6.4 |