Provided by: inn2_2.7.3~20241006-1_amd64 
NAME
incoming.conf - Configuration of incoming news feeds
IN A NUTSHELL
The incoming.conf file configures from which remote peers innd accepts NNTP feeds.
A common entry to allow "news.server.com" as an incoming peer is:
peer news.server.com {
hostname: "news.server.com"
}
The port used for incoming feeds is the one innd is listening on (usually port 119 or
433).
Peer entries are read in the order they appear in the configuration file. The first peer
entry with a hostname value matching the incoming connection will be used to grant access
to the remote peer. Subsequent entries will be discarded.
After any changes, run "inncheck" to perform basic syntax checks, and reload this
configuration file with the following command:
ctlinnd reload incoming.conf 'new peer'
DESCRIPTION
The file pathetc/incoming.conf consists of three types of entries: key/value, peer and
group. Comments are from the hash character "#" to the end of the line. Blank lines are
ignored. All key/value entries within each type must not be duplicated. Key/value
entries are a keyword immediately followed by a colon, at least one blank and a value.
For example:
max-connections: 10
A legal key does not contains blanks, colons, nor "#". There are three different types of
values: integers, booleans, and strings. Integers are as to be expected. A boolean value
is either "true", "yes", "on", "false", "no" or "off" (case is not significant). A string
value is any other sequence of characters. If the string needs to contain whitespace,
then it must be quoted with double quotes.
Peer entries look like:
peer <name> {
# body
}
The word "peer" is required. <name> is a label for this peer. It is any string valid as
a key. The body of a peer entry contains some number of key/value entries.
Group entries look like:
group <name> {
# body
}
The word "group" is required. <name> is any string valid as a key. The body of a group
entry contains any number of the three types of entries. So key/value pairs can be
defined inside a group, and peers can be nested inside a group, and other groups can be
nested inside a group. Key/value entries that are defined outside of all peer and group
entries are said to be at global scope. Global key/value entries act as defaults for
peers. When innd looks for a specific value in a peer entry (for example, the maximum
number of connections to allow), if the value is not defined in the peer entry, then the
enclosing groups are examined for the entry (starting at the closest enclosing group). If
there are no enclosing groups, or the enclosing groups don't define the key/value, then
the value at global scope is used. A small example could be:
# Global value applied to all peers that have no value of their own.
max-connections: 5
# A peer definition.
peer uunet {
hostname: usenet1.uu.net
}
peer vixie {
hostname: gw.home.vix.com
max-connections: 10 # Override global value.
}
# A group of two peers which can open more connections than normal.
group fast-sites {
max-connections: 15
# Another peer. The max-connections value from the
# fast-sites group scope is used.
peer data.ramona.vix.com {
hostname: data.ramona.vix.com
}
peer bb.home.vix.com {
hostname: bb.home.vix.com
max-connections: 20 # He can really cook.
}
}
Given the above configuration file, the defined peers would have the following values for
the max-connections key.
uunet 5
vixie 10
data.ramona.vix.com 15
bb.home.vix.com 20
PARAMETERS
The following keys are allowed:
hold-time
This key requires a positive integer value. It defines the hold time before closing,
if the connection is over max-connections. A value of zero specifies immediate close.
The default is "0".
hostname
This key requires a string value. It is a list of hostnames separated by a comma. A
hostname is either a fully qualified domain name that resolves to the IPv4 or IPv6
address of the peer, or the dotted-quad IP address of the peer for IPv4, or the colon-
separated IP address of the peer for IPv6. If this key is not present in a peer
block, the hostname defaults to the label of the peer.
identd
This key requires a string value. It is used if you wish to require a peer's user
name retrieved through identd(8) match the specified string. Note that currently innd
does not implement any timeout in identd callbacks, so enabling this option may cause
innd to hang if the remote peer does not respond to ident callbacks in a reasonable
timeframe. The default is an empty string, that is to say no ident daemon.
ignore
This key requires a boolean value. Setting this entry to true causes innd to answer
negatively to proposals from the remote peer to send you articles. The default is
false.
More technically, if ignore is true, innd will refuse every Message-ID proposed to be
sent via CHECK or IHAVE by this peer, thus behaving as though it already has the
article. A complete article sent by this peer via TAKETHIS (because it does not first
query with CHECK, or it does not take into account the refusal response code from a
previous CHECK) will still be accepted.
list
This key requires a boolean value. It defines whether a peer is allowed to issue LIST
commands. The default is true, that is to say it can.
max-connections
This key requires a positive integer value. It defines the maximum number of
connections allowed. A value of zero specifies an unlimited number of maximum
connections ("unlimited" or "none" can be used as synonyms). The default is "0".
password
This key requires a string value. It is used if you wish to require a peer to supply
a password via AUTHINFO USER/PASS. The default is an empty string, that it to say no
password is expected.
Note that innd will accept any username provided by the remote peer as long as the
password corresponds. (As the username is mandatory in the authentication protocol,
innd expects one but does nothing with it.)
patterns
This key requires a string value. It is a list of newsfeeds(5)-style list of
newsgroups which are to be accepted from this host. The default is the string "*",
that is to say all groups are accepted.
resendid
This key requires a boolean value. When set to true, innd asks the remote peer to
retry later to send the proposed article (which happens when another peer has already
offered to send it, but has not yet), using "431" (response to CHECK, in streaming
mode) or "436" (response to IHAVE in non-streaming mode) codes. When set to false,
innd does not ask any new attempt (which will lead to the loss of an article in case
the other peer does not send it), using "438" (response to CHECK) or "435" (response
to IHAVE) codes. The deferral feature can be useful for peers that resend messages
right away, as innfeed does. The default is true: the deferral feature is used so
that the peer receives "431" and "436" codes, and therefore resends the article later.
skip
This key requires a boolean value. Setting this entry causes this peer to be skipped.
The default is false.
streaming
This key requires a boolean value. It defines whether streaming commands (CHECK and
TAKETHIS) are allowed from this peer. The default is true.
xbatch
This key requires a boolean value. It defines whether a peer is allowed to issue
XBATCH commands. The default is false, that is to say it cannot.
HISTORY
Written by Fabien Tassin <fta@sofaraway.org> for InterNetNews. Converted to POD by Julien
Elie.
SEE ALSO
inn.conf(5), innd(8), libinn_uwildmat(3), newsfeeds(5).