1INCOMING.CONF(5) InterNetNews Documentation INCOMING.CONF(5)
2
6 incoming.conf - Configuration of incoming news feeds
7
9 The incoming.conf file configures from which remote peers innd accepts
10 NNTP feeds.
11 A common entry to allow "news.server.com" as an incoming peer is:
13 peer news.server.com {
15 hostname: "news.server.com"
16 }
17 The port used for incoming feeds is the one innd is listening on
19 (usually port 119 or 433).
20 After any changes, run "inncheck" to perform basic syntax checks, and
22 reload this configuration file with the following command:
23 ctlinnd reload incoming.conf 'new peer'
25
27 The file pathetc/incoming.conf consists of three types of entries:
28 key/value, peer and group. Comments are from the hash character "#" to
29 the end of the line. Blank lines are ignored. All key/value entries
30 within each type must not be duplicated. Key/value entries are a
31 keyword immediately followed by a colon, at least one blank and a
32 value. For example:
33 max-connections: 10
35 A legal key does not contains blanks, colons, nor "#". There are three
37 different types of values: integers, booleans, and strings. Integers
38 are as to be expected. A boolean value is either "true" or "false"
39 (case is significant). A string value is any other sequence of
40 characters. If the string needs to contain whitespace, then it must be
41 quoted with double quotes.
42 Peer entries look like:
44 peer <name> {
46 # body
47 }
48 The word "peer" is required. <name> is a label for this peer. It is
50 any string valid as a key. The body of a peer entry contains some
51 number of key/value entries.
52 Group entries look like:
54 group <name> {
56 # body
57 }
58 The word "group" is required. <name> is any string valid as a key.
60 The body of a group entry contains any number of the three types of
61 entries. So key/value pairs can be defined inside a group, and peers
62 can be nested inside a group, and other groups can be nested inside a
63 group. Key/value entries that are defined outside of all peer and
64 group entries are said to be at global scope. Global key/value entries
65 act as defaults for peers. When innd looks for a specific value in a
66 peer entry (for example, the maximum number of connections to allow),
67 if the value is not defined in the peer entry, then the enclosing
68 groups are examined for the entry (starting at the closest enclosing
69 group). If there are no enclosing groups, or the enclosing groups
70 don't define the key/value, then the value at global scope is used. A
71 small example could be:
72 # Global value applied to all peers that have no value of their own.
74 max-connections: 5
75 # A peer definition.
77 peer uunet {
78 hostname: usenet1.uu.net
79 }
80 peer vixie {
82 hostname: gw.home.vix.com
83 max-connections: 10 # Override global value.
84 }
85 # A group of two peers which can open more connections than normal.
87 group fast-sites {
88 max-connections: 15
89 # Another peer. The max-connections value from the
91 # fast-sites group scope is used.
92 peer data.ramona.vix.com {
93 hostname: data.ramona.vix.com
94 }
95 peer bb.home.vix.com {
97 hostname: bb.home.vix.com
98 max-connections: 20 # He can really cook.
99 }
100 }
101 Given the above configuration file, the defined peers would have the
103 following values for the max-connections key.
104 uunet 5
106 vixie 10
107 data.ramona.vix.com 15
108 bb.home.vix.com 20
109
111 The following keys are allowed:
112 hold-time
114 This key requires a positive integer value. It defines the hold
115 time before closing, if the connection is over max-connections. A
116 value of zero specifies immediate close. The default is 0.
117 hostname
119 This key requires a string value. It is a list of hostnames
120 separated by a comma. A hostname is either a fully qualified
121 domain name that resolves to the IPv4 or IPv6 address of the peer,
122 or the dotted-quad IP address of the peer for IPv4, or the colon-
123 separated IP address of the peer for IPv6. If this key is not
124 present in a peer block, the hostname defaults to the label of the
125 peer.
126 identd
128 This key requires a string value. It is used if you wish to
129 require a peer's user name retrieved through identd(8) match the
130 specified string. Note that currently innd does not implement any
131 timeout in identd callbacks, so enabling this option may cause innd
132 to hang if the remote peer does not respond to ident callbacks in a
133 reasonable timeframe. The default is an empty string, that is to
134 say no ident daemon.
135 ignore
137 This key requires a boolean value. Setting this entry to true
138 causes innd to answer negatively to proposals from the remote peer
139 to send you articles. The default is false.
140 More technically, if ignore is true, innd will refuse every
142 Message-ID proposed to be sent via CHECK or IHAVE by this peer,
143 thus behaving as though it already has the article. A complete
144 article sent by this peer via TAKETHIS (because it does not first
145 query with CHECK, or it does not take into account the refusal
146 response code from a previous CHECK) will still be accepted.
147 list
149 This key requires a boolean value. It defines whether a peer is
150 allowed to issue LIST commands. The default is true, that is to
151 say it can.
152 max-connections
154 This key requires a positive integer value. It defines the maximum
155 number of connections allowed. A value of zero specifies an
156 unlimited number of maximum connections ("unlimited" or "none" can
157 be used as synonyms). The default is 0.
158 password
160 This key requires a string value. It is used if you wish to
161 require a peer to supply a password via AUTHINFO USER/PASS. The
162 default is an empty string, that it to say no password is expected.
163 Note that innd will accept any username provided by the remote peer
165 as long as the password corresponds. (As the username is mandatory
166 in the authentication protocol, innd expects one but does nothing
167 with it.)
168 patterns
170 This key requires a string value. It is a list of
171 newsfeeds(5)-style list of newsgroups which are to be accepted from
172 this host. The default is the string "*", that is to say all
173 groups are accepted.
174 resendid
176 This key requires a boolean value. When set to true, innd asks the
177 remote peer to retry later to send the proposed article (which
178 happens when another peer has already offered to send it, but has
179 not yet), using 431 (response to CHECK, in streaming mode) or 436
180 (response to IHAVE in non-streaming mode) codes. When set to
181 false, innd does not ask any new attempt (which will lead to the
182 loss of an article in case the other peer does not send it), using
183 438 (response to CHECK) or 435 (response to IHAVE) codes. The
184 deferral feature can be useful for peers that resend messages right
185 away, as innfeed does. The default is true: the deferral feature
186 is used so that the peer receives 431 and 436 codes, and therefore
187 resends the article later.
188 skip
190 This key requires a boolean value. Setting this entry causes this
191 peer to be skipped. The default is false.
192 streaming
194 This key requires a boolean value. It defines whether streaming
195 commands (CHECK and TAKETHIS) are allowed from this peer. The
196 default is true.
197 xbatch
199 This key requires a boolean value. It defines whether a peer is
200 allowed to issue XBATCH commands. The default is false, that is to
201 say it cannot.
202
204 Written by Fabien Tassin <fta@sofaraway.org> for InterNetNews.
205 Converted to POD by Julien Elie.
206
208 inn.conf(5), innd(8), libinn_uwildmat(3), newsfeeds(5).
209INN 2.7.0 2022-07-10 INCOMING.CONF(5)