=head1 NAME

innfeed.conf - Configuration file for innfeed

=head1 IN A NUTSHELL

The I<innfeed.conf> file configures to which remote peers B<innfeed> sends
NNTP feeds.

A common entry to parameterize C<news.server.com> as an outgoing feed is:

    peer news.server.com {
        ip-name: "news.server.com"
    }

If standard NNTP port 119 is not used, you may specify an alternate port as
follows:

    peer news.server.com {
        ip-name: "news.server.com"
        port-number: 433
    }

After any changes, run C<inncheck> to perform basic syntax checks, and
reload this configuration file with the following command which makes B<innd>
respawn a new instance of B<innfeed> (assuming C<innfeed!> is the name of the
corresponding channel feed in F<newsfeeds>):

    ctlinnd flush innfeed!

=head1 DESCRIPTION

The configuration file F<innfeed.conf> in I<pathetc> is used to control
the innfeed(8) program.  It is a fairly free-format file that consists
of three types of entries: I<key>:I<value>, I<peer> and I<group>.
Comments are from the hash character C<#> to the end of the line.

I<key>:I<value> entries are a keyword and a value separated by a colon
(which can itself be surrounded by whitespace).  For example:

    max-connections: 10

A legal I<key> starts with a letter and contains only letters, digits,
and the C<_> and C<-> characters.  There are 5 different types of values:
integers, floating-point numbers, characters, booleans, and strings.

Integer and floating-point numbers are as to be expected, except that
exponents in floating-point numbers are not supported.  A boolean value
is either C<true> or C<false> (case is not significant).  A character
value is a single-quoted character as defined by the C-language.  A string
value is any other sequence of characters.  If the string needs to contain
whitespace, then it must be quoted with double quotes, and uses the same
format for embedding non-printing characters as normal C-language string.

Peer entries look like:

    peer <name> {
        # body ...
    }

The word C<peer> is required.  The I<< <name> >> is the same as the site
name in INN's F<newsfeeds> configuration file.  The body of a peer entry
contains some number (possibly zero) of I<key>:I<value> entries.

Group entries look like:

    group <name> {
        # body ...
    }

The word C<group> is required.  The I<< <name> >> is any string valid as
a key.  The body of a group entry contains any number of the three types of
entries.  So I<key>:I<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.

I<key>:I<value> entries that are defined outside of all I<peer> and I<group>
entries are said to be at "global scope".  There are global I<key>:I<value>
entries that apply to the process as a whole (for example the location of
the backlog file directory), and there are global I<key>:I<value> entries
that act as defaults for peers.  When B<innfeed> looks for a specific value
in a peer entry (for example, the maximum number of connections to set up),
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 do not define
the I<key>:I<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.  "uunet" is the name used by innd
    # in the newsfeeds configuration file.
    peer uunet {
        ip-name: usenet1.uu.net
    }

    peer vixie {
        ip-name: gw.home.vix.com
        max-connections: 10       # Override global value.
    }

    # A group of two peers which can handle more connections
    # than normal.
    group fast-sites {
        max-connections: 15

        # Another peer.  The "max-connections" value from the
        # "fast-sites" group scope is used.  The "ip-name" value
        # defaults to the peer's name.
        peer data.ramona.vix.com {
        }

        peer 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

B<innfeed> ignores I<key>:I<value> pairs it is not interested in.
Some configuration file values can be set via a command-line option,
in which case that setting overrides the settings in the file.

Configuration files can be included in other configuration files via
the syntax:

    $INCLUDE filename

There is a maximum nesting depth of 10.

For a fuller example configuration file, see the supplied F<innfeed.conf>.

=head1 GLOBAL VALUES

The following listing show all the keys that apply to the process as
whole.  These are not required (compiled-in defaults are used where needed).

=over 4

=item I<news-spool>

This key requires a pathname value and defaults to I<patharticles>
in F<inn.conf>.  It specifies where the top of the article spool is.
This corresponds to the B<-a> command-line option.

=item I<input-file>

This key requires a pathname value.  It specifies the pathname (relative to
the I<backlog-directory> value) that should be read in funnel-file mode.
This corresponds to giving a filename as an argument on the command-line
(i.e. its presence also implies that funnel-file mode should be used).

The default is unset; B<innfeed> then runs in channel or batch mode.

=item I<pid-file>

This key requires a pathname value and defaults to F<innfeed.pid>.
It specifies the pathname (relative to I<pathrun> in F<inn.conf>)
where the pid of the B<innfeed> process should be stored.  This corresponds
to the B<-p> command-line option.

=item I<debug-level>

This key defines the debug level for the process.  Default is C<0>.
A non-zero number generates a lot of messages to stderr, or to the
config-defined I<log-file>.  This corresponds to the B<-d> command-line
option.

If a file named F<innfeed.debug> exists in the I<pathlog> directory (as
set in F<inn.conf>), then I<debug-level> is automatically set to C<1>.
This is a cheap way of avoiding continual reloading of the F<newsfeeds>
file when debugging.  Note that debug messages still go to I<log-file>.

=item I<debug-shrinking>

This key requires a boolean value and defaults to false (the debug file is
allowed to grow without bound).  If set to true, this file is truncated when
its size reaches a certain limit.  See I<backlog-limit> for more details.

=item I<initial-sleep>

This key requires a positive integer.  The default value is C<2>.  It defines
the number of seconds to wait when B<innfeed> (or a fork) starts, before
beginning to open connections to remote hosts.

=item I<fast-exit>

This key requires a boolean value and defaults to false.  If set to true,
when B<innfeed> receives a SIGTERM or SIGQUIT signal, it will close its
listeners as soon as it can, even if it means dropping articles.

=item I<use-mmap>

This key requires a boolean value and defaults to true.  When B<innfeed>
is given file names to send (a fairly rare use case) instead of storage
API tokens, it specifies whether mmaping should be used if B<innfeed>
has been built with mmap(2) support.  If article data on disk is not in
NNTP-ready format (CR/LF at the end of each line), then after mmaping,
the article is read into memory and fixed up, so mmaping has no positive
effect (and possibly some negative effect depending on your system),
and so in such a case this value should be C<false>, which corresponds
to the B<-M> command-line option.

=item I<log-file>

This key requires a pathname value and defaults to F<innfeed.log>.
It specifies where any logging messages that could not be sent via syslog(3)
should go (such as those generated when a positive value for I<debug-value>
is used).  This corresponds to the B<-l> command-line option.

This pathname is relative to I<pathlog> in F<inn.conf>.

=item I<log-time-format>

This key requires a format string suitable for strftime(3).  It is used
for messages sent via syslog(3) and to the I<status-file>.  Default value
is C<%a %b %d %H:%M:%S %Y>.

=item I<backlog-directory>

This key requires a pathname value and defaults to F<innfeed>.  It specifies
where the current B<innfeed> process should store backlog files.
This corresponds to the B<-b> command-line option.

This pathname is relative to I<pathspool> in F<inn.conf>.

=item I<backlog-highwater>

This key requires a positive integer value and defaults to C<5>.
It specifies how many articles should be kept on the backlog file queue
before starting to write new entries to disk.

=item I<backlog-ckpt-period>

This key requires a positive integer value and defaults to C<30>.
It specifies how many seconds elapse between checkpoints of the input
backlog file.  Too small a number will mean frequent disk accesses; too
large a number will mean after a crash, B<innfeed> will re-offer more
already-processed articles than necessary.

=item I<backlog-newfile-period>

This key requires a positive integer value and defaults to C<600>.
It specifies how many seconds elapse before each check for externally
generated backlog files that are to be picked up and processed.

=item I<backlog-rotate-period>

This key requires a positive integer value and defaults to C<60>.
It specifies how many seconds elapse before B<innfeed> checks for a
manually created backlog file and moves the output backlog file to the
input backlog file.

=item I<dns-retry>

This key requires a positive integer value and defaults to C<900>.
It defines the number of seconds between attempts to re-lookup host
information that previously failed to be resolved.

=item I<dns-expire>

This key requires a positive integer value and defaults to C<86400>.
It defines the number of seconds between refreshes of name to address
DNS translation.  This is so long-running processes do not get stuck with
stale data, should peer IP addresses change.

=item I<gen-html>

This key requires a boolean value and defaults to false.  It specifies
whether the I<status-file> should be HTML-ified.

=item I<status-file>

This key requires a pathname value and defaults to F<innfeed.status>.
An absolute pathname can be used.  It specifies the pathname (relative
to I<pathhttp> when I<gen-html> is true; otherwise, I<pathlog> as set in
F<inn.conf>) where the periodic status of the B<innfeed> process should
be stored.  This corresponds to the B<-S> command-line option.

=item I<connection-stats>

This key requires a boolean value and defaults to false.  If the value
is true, then whenever the transmission statistics for a peer are logged,
each active connection logs its own statistics.  This corresponds to the
B<-z> command-line option.

=item I<host-queue-highwater>

This key requires a positive integer value and defaults to C<10>.
It defines how many articles will be held internally for a peer before
new arrivals cause article information to be spooled to the backlog file.

=item I<stats-period>

This key requires a positive integer value and defaults to C<600>.
It defines how many seconds B<innfeed> waits between generating statistics
on transfer rates.

=item I<stats-reset>

This key requires a positive integer value and defaults to C<43200>.
It defines how many seconds B<innfeed> waits before resetting all internal
transfer counters back to zero (after logging one final time).  This is
so a B<innfeed> process running more than a day will generate "final"
stats that will be picked up by logfile processing scripts.

=item I<initial-reconnect-time>

This key requires a positive integer value and defaults to C<30>.
It defines how many seconds to first wait before retrying to reconnect
after a connection failure.  If the next attempt fails too, then the
reconnect time is approximately doubled until the connection succeeds,
or I<max-reconnect-time> is reached.

=item I<max-reconnect-time>

This key requires an integer value and defaults to C<3600>.  It defines
the maximum number of seconds to wait between attempt to reconnect
to a peer.  The initial value for reconnection attempts is defined by
I<initial-reconnect-time>, and it is doubled after each failure, up to
this value.

=item I<stdio-fdmax>

This key requires a non-negative integer value and defaults to C<0>.
If the value is greater than zero, then whenever a network socket file
descriptor is created and it has a value I<less than> this, the file
descriptor will be dup'ed to bring the value up greater than this.  This is
to leave lower numbered file descriptors free for stdio.  Certain systems,
Sun's in particular, require this.  SunOS 4.1.x usually requires a value
of 128 and Solaris requires a value of 256.  The default if this is not
specified, is C<0>.

=back

=head2 Special keys for B<imapfeed>

The following keys are used with B<imapfeed> to authenticate to a remote
host.  Several parameters may be included at global scope:

=over 4

=item I<deliver-authname>

The authname is who you want to authenticate as.

=item I<deliver-password>

This is the appropriate password for authname.

=item I<deliver-username>

The username is who you want to "act" as, that is, who is actually going
to be using the server.

=item I<deliver-realm>

In this case, the "realm" is the realm in which the specified authname
is valid.  Currently this is only needed by the DIGEST-MD5 SASL mechanism.

=item I<deliver-rcpt-to>

A printf(3)-style format string for creating the envelope recipient address.
The pattern MUST include a single string specifier which will be replaced
with the newgroup (e.g. C<bb+%s>).  The default is C<+%s>.

=item I<deliver-to-header>

An optional printf(3)-style format string for creating a To header field
to be prepended to the article.  The pattern MUST include a single string
specifier which will be replaced with the newgroup (e.g. C<post+%s@domain>).
If not specified, the To header field will not be prepended.

=back

=head1 GLOBAL PEER DEFAULTS

All the I<key>:I<value> pairs mentioned in this section can be specified at
global scope.  They may also be specified inside a group or peer definition.
Note that when peers are added dynamically (i.e. when B<innfeed> receives
an article for an unspecified peer), it will add the peer site using the
parameters specified at global scope.

=head2 Required keys

No keys are currently required.  They all have a default value, if not
present in the configuration file.

=head2 Optional keys

The following keys are optional:

=over 4

=item I<article-timeout>

This key requires a non-negative integer value.  The default value is C<600>.
If no articles need to be sent to the peer for this many seconds, then
the peer is considered idle and all its active connections are torn down.

=item I<response-timeout>

This key requires a non-negative integer value.  The default value is C<300>.
It defines the maximum amount of time to wait for a response from the peer
after issuing a command.

=item I<initial-connections>

This key requires a non-negative integer value.  The default value is C<1>.
It defines the number of connections to be opened immediately when setting
up a peer binding.  A value of C<0> means no connections will be created
until an article needs to be sent.

=item I<max-connections>

This key requires a positive integer value.  The default value is C<2> but
may be increased if needed or for large feeds.  It defines the maximum
number of connections to run in parallel to the peer.  A value of C<0>
specifies an unlimited number of maximum connections.  In general,
use of an unlimited number of maximum connections is not recommended.
Do not ever set I<max-connections> to zero with I<dynamic-method> 0 set,
as this will saturate peer hosts with connections.

=item I<close-period>

This key requires a positive integer value and defaults to C<86400>.  It is
the maximum number of seconds a connection should be kept open.  Some NNTP
servers do not deal well with connections being held open for long periods.

=item I<dynamic-method>

This key requires an integer value between 0 and 3.  The default value is C<3>.
It controls how connections are opened, up to the maximum specified by
I<max-connections>.  In general (and specifically, with I<dynamic-method> 0),
a new connection is opened when the current number of connections is below
I<max-connections>, and an article is to be sent while no current connections
are idle.  Without further restraint (i.e. using I<dynamic-method> 0), in
practice this means that I<max-connections> connections are established
while articles are being sent.  Use of other I<dynamic-method> settings
imposes a further limit on the amount of connections opened below that
specified by I<max-connections>.  This limit is calculated in different
ways, depending of the value of I<dynamic-method>.

Users should note that adding additional connections is not always productive
S<-- just> because opening twice as many connections results in a small
percentage increase of articles accepted by the remote peer, this may
be at considerable resource cost both locally and at the remote site,
whereas the remote site might well have received the extra articles sent
from another peer a fraction of a second later.  Opening large numbers of
connections is considered antisocial.

The meanings of the various settings are:

=over 2

=item B<0> (no method)

Increase of connections up to I<max-connections> is unrestrained.

=item B<1> (maximize articles per second)

Connections are increased (up to I<max-connections>) and decreased so as
to maximize the number of articles per second sent, while using the fewest
connections to do this.

=item B<2> (set target queue length)

Connections are increased (up to I<max-connections>) and decreased
so as to keep the queue of articles to be sent within the bounds set
by I<dynamic-backlog-low> and I<dynamic-backlog-high>, while using the
minimum resources possible.  As the queue will tend to fill if the site is
not keeping up, this method ensures that the maximum number of articles
are offered to the peer while using the minimum number of connections to
achieve this.

=item B<3> (combination)

This method uses a combination of methods 1 and 2 above.  For sites accepting
a large percentage of articles, method 2 will be used to ensure these sites
are offered as complete a feed as possible.  For sites accepting a small
percentage of articles, method 1 is used, to minimize remote resource usage.
For intermediate sites, an appropriate combination is used.

=back

=item I<dynamic-backlog-low>

This key requires a floating-point value between 0 and 100.  It represents
(as a percentage) the low water mark for the host queue.  If the host queue
falls below this level while using I<dynamic-method> 2 or 3, and if 2 or
more connections are open, B<innfeed> will attempt to drop connections to
the host.  An Infinite Impulse Response (IIR) filter is applied to the
value to prevent connection flap (see I<dynamic-filter>).  The default
value is C<20.0>.  This value must be smaller than I<dynamic-backlog-high>.

=item I<dynamic-backlog-high>

This key requires a floating-point value between 0 and 100.  It represents
(as a percentage) the high water mark for the host queue.  If the host
queue rises above this level while using I<dynamic-method> 2 or 3, and
if less than I<max-connections> are open to the host, B<innfeed> will
attempt to open further connections to the host.  An Infinite Impulse
Response (IIR) filter is applied to the value to prevent connection flap
(see I<dynamic-filter>).  The default value is C<50.0>.  This value must
be larger than I<dynamic-backlog-low>.

=item I<dynamic-backlog-filter>

This key requires a floating-point value between 0 and 1.  It represents
the filter coefficient used by the Infinite Impulse Response (IIR)
filter used to implement I<dynamic-method> 2 and 3.  The default value
of this filter is C<0.7>, giving a time constant of 1/(1-0.7) articles.
Higher values will result in slower response to queue fullness changes;
lower values in faster response.

=item I<max-queue-size>

This key requires a positive integer value.  The default value is C<20>.
It defines the maximum number of articles to process at one time when using
streaming to transmit to a peer.  Larger numbers mean more memory consumed as
articles usually get pulled into memory (see the description of I<use-mmap>).

=item I<streaming>

This key requires a boolean value.  Its default value is true.  It defines
whether streaming commands are used to transmit articles to the peers.

=item I<no-check-high>

This key requires a floating-point number which must be in the range
[0.0, 100.0].  When running transmitting with the streaming commands,
B<innfeed> attempts an optimization called "no-CHECK mode".  This involves
I<not> asking the peer if it wants the article, but just sending it.
This optimization occurs when the percentage of the articles the peer has
accepted gets larger than this number.  If this value is set to C<100.0>,
then this effectively turns off no-CHECK mode, as the percentage can never
get above 100.0.  If this value is too small, then the number of articles
the peer rejects will get bigger (and your bandwidth will be wasted).
The default value of C<95.0> usually works pretty well.

=item I<no-check-low>

This key requires a floating-point number which must be in the range
[0.0, 100.0], and it must be smaller that the value for I<no-check-high>.
When running in no-CHECK mode, as described above, if the percentage
of articles the remote server accepts drops below this number, then the
no-CHECK optimization is turned off until the percentage gets above the
I<no-check-high> value again.  If there is small difference between this
and the I<no-check-high> value (less than about 5.0), then B<innfeed> may
frequently go in and out of no-CHECK mode.  If the difference is too big,
then it will make it harder to get out of no-CHECK mode when necessary
(wasting bandwidth).  Keeping this to between 5.0 and 10.0 less than
B<no-check-high> usually works pretty well.  The default value is C<90.0>.

=item I<no-check-filter>

This is a floating-point value representing the time constant, in articles,
over which the CHECK/no-CHECK calculations are done.  The default value is
C<50.0>, which will implement an Infinite Impulse Response (IIR) filter
of time constant 50.  This roughly equates to making a decision about
the mode over the previous 50 articles.  A higher number will result in
a slower response to changing percentages of articles accepted; a lower
number will result in a faster response.

=item I<port-number>

This key requires a positive integer value.  It defines the TCP/IP port
number to use when connecting to the remote.  Usually, port number 119
is used, which is the default value.

=item I<force-ipv4>

This key requires a boolean value.  By default, it is set to false.
Setting it to true is the same as setting I<bindaddress6> to C<none>
and removing I<bindaddress> from C<none> if it was set.

=item I<drop-deferred>

This key requires a boolean value.  By default, it is set to false.
When set to true, and a peer replies with code 431 or 436 (try again later),
B<innfeed> just drops the article and does not try to re-send it.  This is
useful for some peers that keep on deferring articles for a long time to
prevent B<innfeed> from trying to offer the same article over and over again.

=item I<min-queue-connection>

This key requires a boolean value.  By default, it is set to false.
When set to true, B<innfeed> will attempt to use a connection with the
least queue size (or the first empty connection).  If this key is set to
true, it is recommended that I<dynamic-method> be set to C<0>.  This allows
for article propagation with the least delay.

=item I<no-backlog>

This key requires a boolean value.  It specifies whether spooling should
be enabled (false, the default) or disabled (true).  Note that when
I<no-backlog> is set, articles reported as spooled are actually silently
discarded.

=item I<backlog-limit>

This key requires a non-negative integer value.  If the number is C<0>
(the default), then backlog files are allowed to grow without bound when the
peer is unable to keep up with the article flow.  If this number is greater
than 0, then it specifies the size (in bytes) the backlog file should get
truncated to when the backlog file reaches a certain limit.  The limit
depends on whether I<backlog-factor> or I<backlog-limit-highwater> is used.

This parameter also applies to the debug file when I<debug-shrinking>
is set to true, and has the same effect on this file as the one has on
backlog files.

=item I<backlog-factor>

This key requires a floating-point value, which must be larger than
1.0.  It is used in conjunction with the peer key I<backlog-limit>.
If I<backlog-limit> has a value greater than zero, then when the backlog
file gets larger than the value I<backlog-limit> * I<backlog-factor>,
then the backlog file will be truncated to the size I<backlog-limit>.

For example, if I<backlog-limit> has a value of C<1000000>, and
I<backlog-factor> has a value of C<2.0>, then when the backlog file gets to
be larger than 2000000 bytes in size, it will be truncated to 1000000 bytes.
The front portion of the file is removed, and the trimming happens on
line boundaries, so the final size may be a bit less than this number.
If I<backlog-limit-highwater> is defined too, then I<backlog-factor>
takes precedence.  The default value of I<backlog-factor> is C<1.1>.

This parameter also applies to the debug file when I<debug-shrinking>
is set to true, and has the same effect on this file as the one has on
backlog files.

=item I<backlog-limit-highwater>

This key requires a positive integer value that must be larger than the value
for I<backlog-limit>.  The default value is C<0>.

If the size of the backlog file gets larger than this value (in bytes),
then the backlog file will be shrunk down to the size of I<backlog-limit>.
If both I<backlog-factor> and I<backlog-limit-highwater> are defined,
then the value of I<backlog-factor> is used.

This parameter also applies to the debug file when I<debug-shrinking>
is set to true, and has the same effect on this file as the one has on
backlog files.

=item I<backlog-feed-first>

This key requires a boolean value.  By default it is set to false.  When set
to true, the backlog is fed before new files.  This is intended to enforce
in-order delivery, so setting this to true when I<initial-connections>
or I<max-connections> is more than 1 is inconsistent.

=item I<bindaddress>

This key requires a string value.  It specifies which outgoing IPv4 address
B<innfeed> should bind the local end of its connection to.  It must be an
IPv4 address in dotted-quad format (nnn.nnn.nnn.nnn), C<any>, or C<none>.
If not set or set to C<any>, B<innfeed> defaults to letting the kernel
choose this address.  If set to C<none>, B<innfeed> will not use IPv4 for
outgoing connections to peers in this scope (i.e. it forces IPv6).

If not set in F<innfeed.conf>, B<innfeed> defaults to the value of
I<sourceaddress> from F<inn.conf> (which by default is unset).

=item I<bindaddress6>

This key requires a string value.  It behaves like I<bindaddress> except
for outgoing IPv6 connections.  It must be in numeric IPv6 format (note
that a value containing colons must be enclosed in double quotes), C<any>,
or C<none>.  If set to C<none>, B<innfeed> will not use IPv6 for outgoing
connections to peers in this scope.

If not set in F<innfeed.conf>, B<innfeed> defaults to the value of
I<sourceaddress6> from F<inn.conf> (which by default is unset).

=item I<username>

This key requires a string value.  If the value is defined, then B<innfeed>
tries to authenticate by AUTHINFO USER and this value used for user name.
I<password> must also be defined, if this key is defined.

=item I<password>

This key requires a string value.  The value is the password used for
AUTHINFO PASS.  I<username> must also be defined, if this key is defined.

=back

=head1 PEER VALUES

As previously explained, the peer definitions can contain redefinitions
of any of the I<key>:I<value> pairs described in the section about global
peer defaults above.  There is one I<key>:I<value> pair that is specific
to a peer definition.

=over 4

=item I<ip-name>

This key requires a word value.  The word is either one of the host's FQDNs,
or the dotted-quad IP address of the peer for IPv4, or the colon-separated
IP address of the peer for IPv6.  If this value is not specified, then
the name of the peer in the enclosing I<peer> block is taken to also
be its I<ip-name>.

=back

=head1 RELOADING

If B<innfeed> gets a SIGHUP signal, then it will reread the configuration
file.  All values at global scope except for I<backlog-directory> can be
changed (although note that I<bindaddress> and I<bindaddress6> changes
will only affect new connections).

Any new peers are added and any missing peers have their connections closed.

The log file is also reopened.

=head1 EXAMPLE

For a comprehensive example, see the sample F<innfeed.conf> distributed
with INN and installed as a starting point.

Here are examples of how to format values:

    eg-string:         "New\tconfig\tfile\n"
    eg-long-string:    "A long string that goes
                       over multiple lines.  The
                       newline is kept in the
                       string except when quoted
                       with a backslash \
                       as here."
    eg-simple-string:  A-no-quote-string
    eg-integer:        10
    eg-boolean:        true
    eg-char:           'a'
    eg-ctrl-g:         '\007'

=head1 HISTORY

Written by James Brister <brister@vix.com> for InterNetNews.  Converted to
POD by Julien Elie.

Earlier versions of B<innfeed> (up to 0.10.1) were shipped separately;
B<innfeed> is now part of INN and shares the same version number.
Please note that the F<innfeed.conf> format has changed dramatically since
S<version 0.9.3>.

=head1 SEE ALSO

inn.conf(5), innfeed(8), newsfeeds(5).

=cut
