=head1 NAME

incoming.conf - Configuration of incoming news feeds

=head1 IN A NUTSHELL

The F<incoming.conf> file configures from which remote peers B<innd> accepts
NNTP feeds.

A common entry to allow C<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 B<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 I<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 C<inncheck> to perform basic syntax checks, and reload
this configuration file with the following command:

    ctlinnd reload incoming.conf 'new peer'

=head1 DESCRIPTION

The file I<pathetc>/incoming.conf consists of three types of entries:
key/value, peer and group.  Comments are from the hash character C<#> 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 C<#>.  There are three
different types of values: integers, booleans, and strings.  Integers are as
to be expected.  A boolean value is either C<true>, C<yes>, C<on>, C<false>,
C<no> or C<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 C<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 C<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 B<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 I<max-connections> key.

    uunet                  5
    vixie                 10
    data.ramona.vix.com   15
    bb.home.vix.com       20

=head1 PARAMETERS

The following keys are allowed:

=over 4

=item I<hold-time>

This key requires a positive integer value.  It defines the hold time
before closing, if the connection is over I<max-connections>.  A value
of zero specifies immediate close.  The default is C<0>.

=item I<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.

=item I<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 B<innd> does not implement any timeout in B<identd>
callbacks, so enabling this option may cause B<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.

=item I<ignore>

This key requires a boolean value.  Setting this entry to true causes B<innd>
to answer negatively to proposals from the remote peer to send you articles.
The default is false.

More technically, if I<ignore> is true, B<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.

=item I<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.

=item I<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 (C<unlimited> or C<none> can be used
as synonyms).  The default is C<0>.

=item I<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 B<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, B<innd> expects one but does nothing with it.)

=item I<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 C<*>, that is to say all groups are accepted.

=item I<resendid>

This key requires a boolean value.  When set to true, B<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 C<431> (response
to CHECK, in streaming mode) or C<436> (response to IHAVE in non-streaming
mode) codes.  When set to false, B<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 C<438> (response to CHECK) or C<435> (response to IHAVE) codes.
The deferral feature can be useful for peers that resend messages right away,
as B<innfeed> does.  The default is true: the deferral feature is used so that
the peer receives C<431> and C<436> codes, and therefore resends the article
later.

=item I<skip>

This key requires a boolean value.  Setting this entry causes this
peer to be skipped.  The default is false.

=item I<streaming>

This key requires a boolean value.  It defines whether streaming commands
(CHECK and TAKETHIS) are allowed from this peer.  The default is true.

=item I<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.

=back

=head1 HISTORY

Written by Fabien Tassin <fta@sofaraway.org> for InterNetNews.  Converted to
POD by Julien Elie.

=head1 SEE ALSO

inn.conf(5), innd(8), libinn_uwildmat(3), newsfeeds(5).

=cut
