NEWSFEEDS(5)



NEWSFEEDS(5)              InterNetNews Documentation              NEWSFEEDS(5)

NAME
       newsfeeds - Determine where Usenet articles are sent

DESCRIPTION
       The file pathetc/newsfeeds specifies how incoming articles should be
       distributed to other programs and files on the server.  It is parsed by
       the InterNetNews server innd(8) when it starts up, or when directed to
       by ctlinnd(8).  innd doesn't send articles to remote sites itself, so
       newsfeeds doesn't directly determine which remote news servers articles
       are sent to.  Instead, it specifies what batch files should be created
       or which programs should be run (and what information should be sent to
       them), and then this information is used by programs like innxmit(8)
       and innfeed(8) to feed articles to remote sites.

       The newsfeeds file isn't used solely to set up feeding accepted
       articles to remote sites but also to pass them (or bits of information
       about them) to any local programs or files that want that data.  For
       example, controlchan(8), a daemon that processes incoming control
       messages, runs out of newsfeeds, as could a news to mail gateway.

       The file is interpreted as a set of lines, parsed according to the
       following rules:  If a line ends with a backslash, the backslash, the
       newline, and any whitespace at the start of the next line is deleted.
       This is repeated until the entire "logical" line is collected.  If the
       logical line is blank or starts with a number sign ("#"), it is
       ignored.

       All other lines are interpreted as feed entries.  An entry should
       consist of four colon-separated fields; two of the fields may have
       optional sub-fields, marked off by a slash.  Fields or sub-fields that
       take multiple parameters should be separated by a comma.  Extra
       whitespace can cause problems and should be avoided.  Except for the
       site names, case is significant.  The format of an entry is:

           sitename[/exclude,exclude,...]\
               :pattern,pattern...[/distribution,distribution...]\
               :flag,flag...\
               :parameter

       Each field is described below.

       The sitename is the name of the site to which a news article can be
       sent.  It is used for writing log entries and for determining if an
       article should be forwarded to a site.  (A "site" is the generic term
       for some destination of newsfeed data; it often corresponds to a remote
       news peer, but doesn't have to.  For example, a local archiving program
       run from newsfeeds is also a "site".)  If sitename already appears in
       the article's Path: header, then the article will not be sent to the
       site.  The name is usually whatever the remote site uses to identify
       itself in the Path: header, but can be almost any word.

       Be careful, though, to avoid having the sitename accidentally match a
       Path: header entry unintentionally.  For this reason, special local
       entries (such as archivers or gateways) should probably end with an
       exclamation point to make sure that they do not have the same name as
       any real site.  For example, "gateway" is an obvious name for the local
       entry that forwards articles out to a mailing list.  If a site with the
       name "gateway" posts an article, when the local site receives the
       article it will see the name in the Path and not send the article to
       its own "gateway" entry.  Since "gateway!" can't appear as an
       individual Path: entry since "!" is a delimiter in the Path: header,
       that would be a better thing to use for sitename.

       (Another way to avoid this problem is with the "Ap" flag; see the
       description below.)

       If an entry has an exclusion sub-field, the article will not be sent to
       that site if any of exclude appear in the Path: header.  (It's
       sometimes convenient to have the sitename be an abbreviated form of the
       name of the remote site, since all the sitenames to which an article is
       sent are written to the log and using shorter sitenames can therefore
       improve performance for large servers.  In this case, the Path: header
       entries of those sites should be given as exclude entries and the "Ap"
       flag used so that the abbreviated sitename doesn't accidentally match
       some other Path: header entry.)

       The same sitename can be used more than once and the appropriate action
       will be taken for each entry that should receive the article, but this
       is recommended only for program feeds to avoid confusion.  Case is not
       significant in site names.

       The comma-separated pattern specifies which groups to send to the site;
       it is interpreted to build a "subscription list" for the site.  The
       default subscription is to get all groups carried by the server.  It is
       a uwildmat(3) pattern supporting poison ("@") wildcards; see the
       uwildmat(3) man page for full details on the pattern matching language.
       pattern will be matched against every newsgroup carried by the server
       and all newsgroups that match will be added to the subscription list
       for the site.

       Normally, a given article (or information about it) is sent to a site
       if any of the newsgroups to which the article was posted are in that
       site's subscription list.  If a newsgroup matches a "@" pattern in
       pattern, then not only is it not added to the subscription list, but
       any articles crossposted to that newsgroup also will not be sent to
       that site even if other newsgroups to which it was crossposted are in
       that site's subscription list.  This is called a poison pattern
       (because matching groups are "poisoned").

       For example, to receive all comp.* groups, but only comp.sources.unix
       within the sources newsgroups, the following pattern can be used:

           comp.*,!comp.sources.*,comp.sources.unix

       Note that the trailing ".*" is required; the pattern has to match the
       whole newsgroup name.  "comp.sources.*" could be written
       "comp.sources*" and would exclude the newsgroup comp.sources (if it
       exists) as well as the groups in the comp.sources.* hierarchy, but note
       that this would also exclude a newsgroup named comp.sources-only
       (whereas the above pattern would add that group to the site
       subscription list since it matches "comp.*" and none of the other
       patterns).

       For another example, to feed alt.* and misc.* to a given site but not
       any articles posted to alt.binaries.warez (even if they're also
       crossposted to other alt.* or misc.* groups), the following pattern can
       be used:

           alt.*,@alt.binaries.warez,misc.*

       Note, however, that if you reversed the "alt.*" and
       "@alt.binaries.warez" entries, this pattern would be equivalent to
       "alt.*,misc.*", since the last matching pattern determines whether a
       given newsgroup matches and the poison logic only applies if the poison
       entry is the last matching entry.

       Control messages follow slightly different propagation rules than
       normal articles; see innd(8) for the details.  Note that most
       subscriptions should have "!junk,!control,!control.*" in their pattern
       list due to those propagation rules (and since "junk" is a special
       internal newsgroup; see wanttrash in inn.conf(5) for more details on
       what it's used for) and that the best way to keep control messages
       local to a site is with a distribution.

       A subscription can be further modified by specifying distributions that
       the site should or should not receive.  The default is to send all
       articles to all sites that subscribe to any of the groups where it has
       been posted, but if an article has a Distribution: header and any
       distributions are specified, then they are checked according to the
       following rules:

       1.  If the Distribution: header matches any of the values in the sub-
           field, the article is sent.

       2.  If a distribution starts with an exclamation point, and it matches
           the Distribution: header, the article is not sent.

       3.  If the Distribution: header does not match any distribution in the
           site's entry and no negations were used, the article is not sent.

       4.  If the Distribution: header does not match any distribution in the
           site's entry and any distribution started with an exclamation
           point, the article is sent.

       If an article has more than one distribution specified, then each one
       is handled according according to the above rules.  If any of the
       specified distributions indicate that the article should be sent, it
       is; if none do, it is not sent.  In other words, the rules are used as
       a logical or.

       It is almost definitely a mistake to have a single feed that specifies
       distributions that start with an exclamation point along with some that
       don't.

       Distributions are text words, not patterns; entries like "*" or "all"
       have no special meaning.

       The flag field is described in "FLAG VALUES".  The interpretation of
       the parameter field depends on the type of feed and is explained in
       more detail in "FEED TYPES".  It can be omitted for some types of
       feeds.

       The site named "ME" is special.  There must be exactly one such entry,
       and it should be the first entry in the file.  If the "ME" entry has an
       exclusion sub-field, incoming articles are rejected completely if any
       of the names specified in that exclusion sub-field appear in their
       Path: headers.  If the "ME" entry has a subscription list, that list is
       prepended to the subscription list of all other entries.  For example,
       "*,!control,!control.*,!junk,!foo.*" could be used to set the default
       subscription list for all other feeds so that local postings are not
       propagated unless "foo.*" explicitly appears in the site's subscription
       list.  This feature tends to be somewhat confusing since the default
       subscription is prepended and can be overridden by other patterns.

       If the "ME" entry has a distribution sub-field, only articles that
       match that distribution list are accepted and all other articles with a
       distribution are rejected.  A common use for this is to put something
       like "/!local" in the "ME" entry to reject local postings from other
       misconfigured sites.  The distribution sub-field of "ME" has no effect
       on the acceptance or rejection of articles that do not have a
       Distribution header field.

       An empty "ME" entry is possible, in which case no exclusion patterns
       will be defined.

       Finally, it is also possible to set variables in newsfeeds and use them
       later in the file.  A line starting with "$" sets a variable.  For
       example:

           $LOCALGROUPS=local.*,example.*
           $CONTROLGROUPS=control,control.*

       This sets the variable "LOCALGROUPS" to "local.*,example.*" and the
       variable "CONTROLGROUPS" to "control,control.*".  They can later be
       used elsewhere in the file, such as in a site entry like:

           news.example.com:$LOCALGROUPS:Tf,Wnm:

       which is then completely equivalent to:

           news.example.com:local.*,example.*:Tf,Wnm:

       Variables aren't solely simple substitution.  If either "!" or "@"
       immediately preceds the variable and the value of the variable contains
       commas, that character will be duplicated before each comma.  This
       somewhat odd-sounding behavior is designed to make it easier to use
       variables to construct feed patterns.  The utility becomes more obvious
       when you observe that the line:

           news.example.net:*,@$LOCALGROUPS,!$CONTROLGROUPS:Tf,Wnm:

       is therefore equivalent to:

           news.example.net:*,@local.*,@example.*,!control,!control.*:Tf,Wnm:

       which (as explained below) excludes all of the groups in $LOCALGROUPS
       and unwanted control articles from the feed to that site.

FLAG VALUES
       The flags parameter specifies miscellaneous parameters, including the
       type of feed, what information should be sent to it, and various
       limitations on what articles should be sent to a site.  They may be
       specified in any order and should be separated by commas.  Flags that
       take values should have the value immediately after the flag letter
       with no whitespace.  The valid flags are:

       < size
           An article will only be sent to this site if it is less than size
           bytes long.  The default is no limit.

       > size
           An article will only be sent to this site if it is greater than
           size bytes long.  The default is no limit.

       A checks
           An article will only be sent to this site if it meets the
           requirements specified in checks, which should be chosen from the
           following set.  checks can be multiple letters if appropriate.
           Note that this flag is not effective on funnel targets; it has to
           be used on every funnel entry (for instance, Af is not effective on
           the innfeed! funnel target and therefore has to be specified on
           every funnelled news site).

           c  Exclude all kinds of control messages.

           C  Only send control messages, not regular articles.

           d  Only send articles with a Distribution: header.  Combined with a
              particular distribution value in the distribution part of the
              site entry, this can be used to limit articles sent to a site to
              just those with a particuliar distribution.

           e  Only send articles where every newsgroup listed in the
              Newsgroups: header exists in the active file.

           f  Don't send articles rejected by filters.  This is only useful
              when dontrejectfiltered is set to true in inn.conf.  With that
              variable set, this lets one accept all articles but not
              propagate filtered ones to some sites.

           j  Propagate articles according to their Newsgroups: header.  This
              is only useful when wanttrash is set to true in inn.conf.  With
              that variable set, articles accepted and filed in "junk" (due to
              wanttrash) are fed to peers based on their subscription pattern
              applied to the Newsgroups: header as though they were accepted
              and all those groups were locally carried.  Otherwise, they are
              propagated to sites that receive the "junk" newsgroup.

              This variable is useful if you want to run INN with a minimal
              active file and propagate all posts.

           o  Only send articles for which overview data was stored.

           O  Send articles to this site that don't have an Injection-Info: or
              X-Trace: header, even if the "O" flag is also given.

           p  Only check the exclusions against the Path: header of articles;
              don't check the site name.  This is useful if your site names
              aren't the same as the Path: entries added by those remote
              sites, or for program feeds where the site name is arbitrary and
              unrelated to the Path: header.

           If both "c" and "C" are given, the last specified one takes
           precedence.

       B high/low
           If a site is being fed by a file, channel, or exploder (see below),
           the server will normally start trying to write the information as
           soon as possible.  Providing a buffer may give better system
           performance and help smooth out overall load if a large batch of
           news comes in.  The value of the this flag should be two numbers
           separated by a slash.  high specifies the point at which the server
           can start draining the feed's I/O buffer, and low specifies when to
           stop writing and begin buffering again; the units are bytes.  The
           default is to do no buffering, sending output as soon as it is
           possible to do so.

       C count
           If this flag is specified, an article will only be sent to this
           site if the number of groups it is posted to, plus the square of
           the number of groups followups would appear in, is no more than
           count.  30 is a good value for this flag, allowing for instance:

           o  crossposts to only 5 groups when followups aren't set;

           o  crossposts to up to 26 groups when followups are set to two
              groups;

           o  crossposts to up to 29 groups when followups are set to a single
              group;

           o  crossposts to up to 30 groups when followups are set to poster.

           Note that if an article does not contain a Followup-To: header
           field, the number of groups followups would appear in is the number
           of groups it is posted to.

       F name
           Specifies the name of the file that should be used if it's
           necessary to begin spooling for the site (see below).  If name is
           not an absolute path, it is taken to be relative to pathoutgoing in
           inn.conf.  If name is a directory, the file togo in that directory
           will be used as the file name.

       G count
           If this flag is specified, an article will only be sent to this
           site if it is posted to no more than count newsgroups.  This has
           the problem of filtering out many FAQs, as well as newsgroup
           creation postings and similar administrative announcements.  Either
           the C flag or the U flag is a better solution.

       H count
           If this flag is specified, an article will only be sent to this
           site if it has count or fewer sites in its Path: line.  This flag
           should only be used as a rough guide because of the loose
           interpretation of the Path: header; some sites put the poster's
           name in the header, and some sites that might logically be
           considered to be one hop become two because they put the posting
           workstation's name in the header.  The default value for count if
           not specified is one.  (Also see the O flag, which is sometimes
           more appropriate for some uses of this flag.)

       I size
           The flag specifies the size of the internal buffer for a file feed.
           If there are more file feeds than allowed by the system, they will
           be buffered internally in least-recently-used order.  If the
           internal buffer grows bigger then size bytes, however, the data
           will be written out to the appropriate file.  The default value is
           16 KB.

       N status
           Restricts the articles sent to this site to those in newsgroups
           with the moderation status given by status.  If status is "m", only
           articles in moderated groups are sent; if status is "u", only
           articles in unmoderated groups are sent.

       O originator
           If this flag is specified, an article will only be sent to this
           site if it contains an Injection-Info: header (or an X-Trace:
           header if no Injection-Info: header is found) and the first field
           of this header matches originator.  originator is a uwildmat(3)
           expression without commas or a list of such expressions, separated
           by "/".  The article is never sent if the first character of the
           pattern begins with "@" and the rest of the pattern matches.  One
           use of this flag is to restrict the feed to locally generated posts
           by using an originator pattern that matches the Injection-Info:
           header added by the local server.

       P priority
           The nice priority that this channel or program feed should receive.
           This should be a positive number between 0 and 20 and is the
           priority that the new process will run with.  This flag can be used
           to raise the priority to normal if you're using the nicekids
           parameter in inn.conf.

       Q hashfeed
           Specifies the hashfeed match expression for this site.  It must be
           in the form "value/mod" or "start-end/mod".  The Message-ID of the
           article is hashed using MD5, which results in a 128-bit hash.  The
           lowest 32 bits are then taken by default as the hashfeed value
           (which is an integer).  If the hashfeed value modulus "mod" plus
           one equals "value" or is between "start" and "end", the article
           will be fed to this site.  All these numbers must be integers.

           It is a deterministic way to control the flow of articles and to
           split a feed.  For instance:

               Q1/2      Feeds about 50% of all articles to this site.
               Q2/2      Feeds the other 50% of all articles.

           Another example with three sites:

               Q1-3/10   Feeds about 30% of all articles.
               Q4-5/10   Feeds about 20% of all articles.
               Q6-10/10  Feeds about 50% of all articles.

           If this flag is specified multiple times, the contents will be
           logically "OR"ed together (just one match is needed).

           You can use an extended syntax of the form "value/mod_offset" or
           "start-end/mod_offset".  As MD5 generates a 128-bit return value,
           it is possible to specify from which byte-offset the 32-bit integer
           used by hashfeed starts.  The default value for "offset" is "_0"
           and thirteen overlapping values from "_0" to "_12" can be used.
           Only up to four totally independent values exist:  "_0", "_4", "_8"
           and "_12".

           Therefore, it allows generating a second level of deterministic
           distribution.  Indeed, if a news server is fed "Q1/2", it can go on
           splitting thanks to "Q1-3/9_4" for instance.  Up to four levels of
           deterministic distribution can be used.

           The algorithm is compatible with the one used by Diablo 5.1 and up.
           If you want to use the legacy quickhashing method used by Diablo
           before 5.1, you can put an "@" sign just after the Q flag (for
           instance "Q@1-3/10", but the distribution of the messages is not
           perfect with this legacy method whose use is discouraged and for
           which offsets cannot be used).

       S size
           If the amount of data queued for the site gets to be larger than
           size bytes, the server will switch to spooling, appending to a file
           specified by the F flag, or pathoutgoing/sitename if F is not
           specified.  Spooling usually happens only for channel or exploder
           feeds, when the spawned program isn't keeping up with its input.

       T type
           This flag specifies the type of feed for this site.  type should be
           a letter chosen from the following set:

               c        Channel
               f        File
               l        Log entry only
               m        Funnel (multiple entries feed into one)
               p        Program
               x        Exploder

           Each feed is described below in "FEED TYPES".  The default is Tf,
           for a file feed.

       U count
           If this flag is specified, an article will only be sent to this
           site if followups to this article would be posted to no more than
           count newsgroups.  (Also see C for a more complex way of handling
           this.)

       W items
           For a file, channel, or exploder feed, this flag controls what
           information will be sent to this site.  For a program feed, only
           the asterisk ("*") has any effect.  items should be chosen from the
           following set:

           b  Size of the article (in wire format, meaning with CRLF at the
              end of each line, periods doubled at the beginning of lines, and
              ending in a line with a single period) in bytes.

           e  The time the article will expire as seconds since epoch if it
              has an Expires: header, 0 otherwise.

           f  The storage API token of the article (the same as "n").  The
              article can be retrieved given the storage API token by using
              sm(8).

           g  The newsgroup the article is in; if cross-posted, then the first
              of the groups to which the article was posted that this site
              gets.  (The difference from "G" is that this sends the newsgroup
              to which the article was posted even if it is a control
              message.)

           h  The history hash key of the article (derived from the message
              ID).

           m  The message ID of the article.

           n  The storage API token of the article.  The article can be
              retrieved given the storage API token by using sm(8).

           p  The time the article was posted a seconds since epoch.

           s  The site that fed the article to the server.  This is taken from
              either the Path: header or the IP address of the sending site
              depending on the value of logipaddr in inn.conf.  If logipaddr
              is true and the IP address is 0.0.0.0 (meaning that the article
              was fed from localhost by a program like rnews(8)), the Path:
              header value will be sent instead.

           t  The time the article was received as seconds since epoch.

           *  The names of the appropriate funnel entries, or all sites that
              get the article (see below for more details).

           D  The value of the Distribution: header of the article, or "?" if
              there is no such header in the article.

           G  Where the article is stored.  If the newsgroup is crossposted,
              this is generally the first of the groups to which it was posted
              that this site receives; however, control messages are filed in
              control or control.*  (which is the difference between this item
              and "g").

           H  All of the headers, followed by a blank line.  The Xref header
              will already be present, and a Bytes header containing the
              article's size in bytes as in the "b" item will be added to the
              headers.  If used, this should be the only item in the list.

           N  The value of the Newsgroups: header.

           P  The value of the Path: header.

           O  Overview data for the article.

           R  Information needed for replication (the Xref header without the
              site name).

           More than one letter can be given.  If multiple items are
           specified, they will be written in the order specified separated by
           spaces.  ("H" should be the only item if given, but if it's not a
           newline will be sent before the beginning of the headers.)  The
           default is Wn.

           The "H" and "O" items are intended for use by programs that create
           news overview databases or require similar information.  WnteO is
           the flag to generate input needed by the overchan(8) program.

           The asterisk ("*") has special meaning.  Normally it expands to a
           space-separated list of all sites that received the current
           article.  If, however, this site is a target of a funnel feed (in
           other words, if it is named by other sites which have the Tm flag),
           then the asterisk expands to the names of the funnel feeds that
           received the article.  Similarly, if the site is a program feed, an
           asterisk in the parameter field will be expanded into the list of
           funnel feeds that received the article.  A program feed cannot get
           the site list unless it is the target of other Tm feeds.

FEED TYPES
       innd provides four basic types of feeds:  log, file, program, and
       channel.  An exploder is a special type of channel.  In addition,
       several entries can feed into the same feed; these are funnel feeds,
       which refer to an entry that is one of the other types.  Funnel feeds
       are partially described above with the description of the W* flag.  A
       funnel feed gets every article that would be sent to any of the feeds
       that funnel into it and normally include the W* flag in their flags so
       that the program processing that feed knows which sites received which
       articles.  The most common funnel feed is innfeed(8).

       Note that the term "feed" is technically a misnomer, since the server
       doesn't transfer articles itself and only writes data to a file,
       program, or log telling another program to transfer the articles.

       The simplest feed is a log feed (Tl).  Other than a mention in the news
       log file, pathlog/news, no data is written out.  This is equivalent to
       a Tf entry writing to /dev/null, except that no file is ever opened.
       Flushing a log feed does nothing.

       A file feed (Tf) is the next simplest type of feed.  When the site
       should receive an article, the specified data is written out to the
       file named by the parameter field.  If parameter is not an absolute
       path, it is taken to be relative to pathoutgoing in inn.conf.  If
       parameter is not given, it defaults to pathoutgoing/sitename.  The file
       name should be unique (two file feeds should not ever point to the same
       file).

       File feeds are designed for use by external programs that periodically
       process the written data.  To cooperate with innd properly, such
       external programs should first rename the batch file and then send a
       flush command for that site to innd using ctlinnd(8).  innd will then
       write out any buffered data, close the file, and reopen it (under the
       original name), and the program can process the data in the renamed
       file at its leisure.  File feeds are most frequently used in
       combination with nntpsend(8).

       A program feed (Tp) spawns a given program for every article that the
       site receives.  The parameter field must be the command line to
       execute, and should contain one instance of %s, which will be replaced
       by the storage API token of the article (the actual article can be
       retrieved by the program using sm(8)).  The program will not receive
       anything on standard input (unlike earlier versions of INN, where the
       article is sent to the program on stdin), and standard output and error
       from the program will be set to the error log (pathlog/errlog).  innd
       will try to avoid spawning a shell if the command has no shell meta-
       characters; this feature can be defeated if necessary for some reason
       by appending a semi-colon to the end of the command.  The full path
       name of the program to be run must be specified unless the command will
       be run by the shell (and it is strongly recommended that the full path
       name always be specified regardless).

       If a program feed is the target of a funnel, and if W* appears in the
       flags of the site, a single asterisk may be present in the parameter
       and will be replaced by a space-separated list of names of the sites
       feeding into the funnel which received the relevant article.  If the
       site is not the target of a funnel, or if the W* flag is not used, the
       asterisk has no special meaning.

       Flushing a program feed does nothing.

       For a channel (Tc) or exploder (Tx) feed, the parameter field again
       names the process to start.  As with program feeds, the full path to
       the program must be specified.  However, rather than spawning the
       program for every article, it is spawned once and then whenever the
       site receives an article, the data specified by the site flags is
       written to the standard input of the spawned program.  Standard output
       and error are set as with program feeds.  If the process exits, it will
       be restarted automatically.  If the process cannot be started, the
       server will spool input to a file named pathoutgoing/sitename and will
       try to start the process again later.

       When a channel or exploder feed is flushed, the server closes its end
       of the pipe to the program's standard input.  Any pending data that has
       not been written will be spooled; see the description of the S flag
       above.  The server will then spawn a new instance of the program.  No
       signal is sent to the program; it is up to the program handling a
       channel or exploder feed to notice end of file on its standard input
       and exit appropriately.

       Exploders are a special type of channel feed.  In addition to the
       channel feed behavior described above, exploders can also be sent
       command lines.  These lines start with an exclamation point and their
       interpretation is up to the exploder.  The following commands are
       generated automatically by the server:

           !newgroup group
           !rmgroup group
           !flush
           !flush site

       These commands are sent whenever the ctlinnd(8) command of the same
       name is received by the server.  In addition, the ctlinnd(8) "send"
       command can be used to send an arbitrary command line to an exploder.
       The primary exploder is buffchan(8).

       Finally, Tm feeds are the input to a funnel.  The parameter field of
       the site should name the site handling articles for all of the funnel
       inputs.

EXAMPLES
       The syntax of the newsfeeds file is so complex because you can specify
       a staggering variety of feeds.  INN is capable of interacting with a
       wide variety of programs that do various things with news articles.
       Far and away the most common two entries in newsfeeds, however, are
       file feeds for nntpsend(8) and funnel feeds for innfeed(8).

       The former look like this:

           feed.example.com:*,!control,!control.*,!junk:Tf,Wnm:

       which generates a file named pathoutgoing/feed.example.com containing
       one line per article consisting of the storage API token, a space, and
       the message ID.

       The latter look like this:

           feed.example.com:*,!control,!control.*,!junk:Tm:innfeed!

       Very similar, except that this is the input to a funnel feed named
       "innfeed!".  One could also write this as:

           example/feed.example.com:*,!control,!control.*,!junk:Ap,Tm:innfeed!

       (note the Ap so that articles that contain just "example" in the Path:
       header will still be sent), which is completely equivalent except that
       this will be logged in pathlog/news as going to the site "example"
       rather than "feed.example.com".

       The typical feed entry for innfeed(8) is a good example of a channel
       feed that's the target of various funnel feeds (make sure the path to
       innfeed is properly set):

           innfeed!:!*:Tc,Wnm*:<pathbin in inn.conf>/innfeed -y

       Note that the pattern for this feed is just "!*" so that it won't
       receive any articles directly.  The feed should only receive those
       articles that would go to one of the funnel feeds that are feeding into
       it.  innfeed(8) will receive one line per article on its standard input
       containing the storage API token, the message ID, and a space-separated
       list of sites that should receive that article.

       Here's a more esoteric example of a channel feed:

           watcher!:*:Tc,Wbnm\
               :exec awk '$1 > 1000000 { print "BIG", $2, $3 }' > /dev/console

       This receives the byte size of each article along with the storage API
       token and message ID, and prints to the console a line for every
       article that's over a million bytes.  This is actually rather a strange
       way to write this since INN can do the size check itself; the following
       is equivalent:

           watcher!:*:Tc,>1000000,Wbnm\
               :exec awk '{ print "BIG", $2, $3}' > /dev/console

       Here's a cute, really simple news to mail gateway that also serves as
       an example of a fairly fancy program feed:

           mailer!:!*:W*,Tp\
               :sm %s | innmail -s "News article" *

       Remember that %s is replaced by the storage API token, so this
       retrieves the article and pipes it into innmail (which is safer than
       programs like Mail(1) because it doesn't parse the body for tilde
       commands) with a given subject line.  Note the use of "*" in the
       command line and W* in the flags; this entry is designed to be used as
       the target of funnel feeds such as:

           peter@example.com:news.software.nntp:Tm:mailer!
           sue@example.com:news.admin.misc:Tm:mailer!

       Suppose that the server receives an article crossposted between
       news.admin.misc and news.software.nntp.  The server will notice that
       the article should be sent to the site "peter@example.com" and the site
       "bob@example.com", both of which funnel into "mailer!", so it will look
       at the "mailer!" site and end up executing the command line:

           sm @...@ | innmail -s "News article" peter@example.com sue@example.com

       which will mail the article to both Peter and Sue.

       Finally, another very useful example of a channel feed:  the standard
       entry for controlchan(8).  Make sure its path is properly set.

           controlchan!\
               :!*,control,control.*,!control.cancel/!collabra-internal\
               :AC,Tc,Wnsm:<pathbin in inn.conf>/controlchan

       This program only wants information about articles posted to a control
       newsgroup other than control.cancel, which due to the sorting of
       control messages described in innd(8) will send it all control messages
       except for cancel messages.  In this case, we also exclude any article
       with a distribution of "collabra-internal".  controlchan gets the
       storage API token, the name of the sending site (for processing old-
       style ihave and sendme control messages, be sure to read about
       logipaddr in controlchan(8)), and the message ID for each article.

       For many other examples, including examples of the special "ME" site
       entry, see the example newsfeeds file distributed with INN.  Also see
       the install documentation that comes with INN for information about
       setting up the standard newsfeeds entries used by most sites.

HISTORY
       Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews.
       Reformatted and rewritten in POD by Russ Allbery <eagle@eyrie.org>.

       $Id: newsfeeds.pod 10283 2018-05-14 12:43:05Z iulius $

SEE ALSO
       active(5), buffchan(8), controlchan(8), ctlinnd(8), inn.conf(5),
       innd(8), innfeed(8), innxmit(8), nntpsend(8), uwildmat(3).

INN 2.6.4                         2018-05-15                      NEWSFEEDS(5)

Man(1) output converted with man2html
list of all man pages