3 newsfeeds - Determine where Usenet articles are sent
7 The file I<pathetc>/newsfeeds specifies how incoming articles should be
8 distributed to other programs and files on the server. It is parsed by
9 the InterNetNews server innd(8) when it starts up, or when directed to by
10 ctlinnd(8). B<innd> doesn't send articles to remote sites itself, so
11 F<newsfeeds> doesn't directly determine which remote news servers articles
12 are sent to. Instead, it specifies what batch files should be created or
13 which programs should be run (and what information should be sent to
14 them), and then this information is used by programs like innxmit(8) and
15 innfeed(8) to feed articles to remote sites.
17 The F<newsfeeds> file isn't used solely to set up feeding accepted
18 articles to remote sites but also to pass them (or bits of information
19 about them) to any local programs or files that want that data. For
20 example, controlchan(8), a daemon that processes incoming control
21 messages, runs out of F<newsfeeds>, as could a news to mail gateway.
23 The file is interpreted as a set of lines, parsed according to the
24 following rules: If a line ends with a backslash, the backslash, the
25 newline, and any whitespace at the start of the next line is deleted.
26 This is repeated until the entire "logical" line is collected. If the
27 logical line is blank or starts with a number sign (C<#>), it is ignored.
29 All other lines are interpreted as feed entries. An entry should consist
30 of four colon-separated fields; two of the fields may have optional
31 sub-fields, marked off by a slash. Fields or sub-fields that take
32 multiple parameters should be separated by a comma. Extra whitespace can
33 cause problems and should be avoided. Except for the site names, case is
34 significant. The format of an entry is:
36 sitename[/exclude,exclude,...]\
37 :pattern,pattern...[/distribution,distribution...]\
41 Each field is described below.
43 The I<sitename> is the name of the site to which a news article can be
44 sent. It is used for writing log entries and for determining if an
45 article should be forwarded to a site. (A "site" is the generic term for
46 some destination of newsfeed data; it often corresponds to a remote news
47 peer, but doesn't have to. For example, a local archiving program run
48 from F<newsfeeds> is also a "site.") If I<sitename> already appears in
49 the article's Path: header, then the article will not be sent to the site.
50 The name is usually whatever the remote site uses to identify itself in
51 the Path: header, but can be almost any word.
53 Be careful, though, to avoid having the I<sitename> accidentally match a
54 Path: header entry unintentionally. For this reason, special local
55 entries (such as archivers or gateways) should probably end with an
56 exclamation point to make sure that they do not have the same name as any
57 real site. For example, C<gateway> is an obvious name for the local entry
58 that forwards articles out to a mailing list. If a site with the name
59 C<gateway> posts an article, when the local site receives the article it
60 will see the name in the Path and not send the article to its own
61 C<gateway> entry. Since C<gateway!> can't appear as an individual Path:
62 entry since C<!> is a delimiter in the Path: header, that would be a
63 better thing to use for I<sitename>.
65 (Another way to avoid this problem is with the C<Ap> flag; see the
68 If an entry has an exclusion sub-field, the article will not be sent to
69 that site if any of I<exclude> appear in the Path: header. (It's
70 sometimes convenient to have the I<sitename> be an abbreviated form of the
71 name of the remote site, since all the I<sitename>s to which an article
72 is sent are written to the log and using shorter I<sitename>s can
73 therefore improve performance for large servers. In this case, the Path:
74 header entries of those sites should be given as I<exclude> entries and
75 the C<Ap> flag used so that the abbreviated I<sitename> doesn't
76 accidentally match some other Path: header entry.)
78 The same I<sitename> can be used more than once and the appropriate action
79 will be taken for each entry that should receive the article, but this is
80 recommended only for program feeds to avoid confusion. Case is not
81 significant in site names.
83 The comma-separated I<pattern> specifies which groups to send to the site;
84 it is interpreted to build a "subscription list" for the site. The
85 default subscription is to get all groups carried by the server. It is a
86 uwildmat(3) pattern supporting poison (C<@>) wildcards; see the uwildmat(3)
87 man page for full details on the pattern matching language. I<pattern>
88 will be matched against every newsgroup carried by the server and all
89 newsgroups that match will be added to the subscription list for the site.
91 Normally, a given article (or information about it) is sent to a site if
92 any of the newsgroups to which the article was posted are in that site's
93 subscription list. If a newsgroup matches a C<@> pattern in I<pattern>,
94 then not only is it not added to the subscription list, but any articles
95 crossposted to that newsgroup also will not be sent to that site even if
96 other newsgroups to which it was crossposted are in that site's
97 subscription list. This is called a poison pattern (because matching
98 groups are "poisoned").
100 For example, to receive all comp.* groups, but only comp.sources.unix
101 within the sources newsgroups, the following I<pattern> can be used:
103 comp.*,!comp.sources.*,comp.sources.unix
105 Note that the trailing C<.*> is required; the pattern has to match the
106 whole newsgroup name. C<comp.sources.*> could be written C<comp.sources*>
107 and would exclude the newsgroup comp.sources (if it exists) as well as the
108 groups in the comp.sources.* hierarchy, but note that this would also
109 exclude a newsgroup named comp.sources-only (whereas the above pattern
110 would add that group to the site subscription list since it matches
111 C<comp.*> and none of the other patterns.
113 For another example, to feed alt.* and misc.* to a given site but not any
114 articles posted to alt.binaries.warez (even if they're also crossposted to
115 other alt.* or misc.* groups), the following pattern can be used:
117 alt.*,@alt.binaries.warez,misc.*
119 Note, however, that if you reversed the C<alt.*> and <@alt.binaries.warez>
120 entries, this pattern would be equivalent to C<alt.*,misc.*>, since the
121 last matching pattern determines whether a given newsgroup matches and the
122 poison logic only applies if the poison entry is the last matching entry.
124 Control messages follow slightly different propagation rules than normal
125 articles; see innd(8) for the details. Note that most subscriptions
126 should have C<!junk,!control,!control.*> in their pattern list due to those
127 propagation rules (and since junk is a special internal newsgroup; see
128 I<wanttrash> in inn.conf(5) for more details on what it's used for) and
129 that the best way to keep control messages local to a site is with a
132 A subscription can be further modified by specifying distributions that
133 the site should or should not receive. The default is to send all
134 articles to all sites that subscribe to any of the groups where it has
135 been posted, but if an article has a Distribution: header and any
136 I<distribution>s are specified, then they are checked according to the
143 If the Distribution: header matches any of the values in the sub-field,
148 If a I<distribution> starts with an exclamation point, and it matches the
149 Distribution: header, the article is not sent.
153 If the Distribution: header does not match any I<distribution> in the
154 site's entry and no negations were used, the article is not sent.
158 If the Distribution: header does not match any I<distribution> in the
159 site's entry and any I<distribution> started with an exclamation point,
164 If an article has more than one distribution specified, then each one is
165 handled according according to the above rules. If any of the specified
166 distributions indicate that the article should be sent, it is; if none do,
167 it is not sent. In other words, the rules are used as a logical or.
169 It is almost definitely a mistake to have a single feed that specifies
170 distributions that start with an exclamation point along with some that
173 Distributions are text words, not patterns; entries like C<*> or C<all>
174 have no special meaning.
176 The I<flag> field is described in L<"FLAG VALUES">. The interpretation of
177 the I<parameter> field depends on the type of feed and is explained in
178 more detail in L<"FEED TYPES">. It can be omitted for some types of
181 The site named C<ME> is special. There must be exactly one such entry,
182 and it should be the first entry in the file. If the C<ME> entry has an
183 exclusion sub-field, incoming articles are rejected completely if any of
184 the names specified in that exclusion sub-field appear in their Path:
185 headers. If the C<ME> entry has a subscription list, that list is
186 prepended to the subscription list of all other entries. For example,
187 C<*,!control,!control.*,!junk,!foo.*> could be used to set the default subscription
188 list for all other feeds so that local postings are not propagated unless
189 C<foo.*> explicitly appears in the site's subscription list. This feature
190 tends to be somewhat confusing since the default subscription is prepended
191 and can be overridden by other patterns.
193 If the C<ME> entry has a distribution sub-field, only articles that match
194 that distribution list are accepted and all other articles are rejected.
195 A common use for this is to put something like C</!local> in the C<ME>
196 entry to reject local postings from other misconfigured sites.
198 Finally, it is also possible to set variables in F<newsfeeds> and use them
199 later in the file. A line starting with C<$> sets a variable. For
202 $LOCALGROUPS=local.*,example.*
204 This sets the variable C<LOCALGROUPS> to C<local.*,example.*>. This
205 variable can later be used elsewhere in the file, such as in a site entry
208 news.example.com:$LOCALGROUPS:Tf,Wnm:
210 which is then completely equivalent to:
212 news.example.com:local.*,example.*:Tf,Wnm:
214 Variables aren't solely simple substitution. If either C<!> or C<@>
215 immediately preceeds the variable and the value of the variable contains
216 commas, that character will be duplicated before each comma. This
217 somewhat odd-sounding behavior is designed to make it easier to use
218 variables to construct feed patterns. The utility becomes more obvious
219 when you observe that the line:
221 news.example.net:*,@$LOCALGROUPS:Tf,Wnm:
223 is therefore equivalent to:
225 news.example.net:*,@local.*,@example.*:Tf,Wnm:
227 which (as explained below) excludes all of the groups in $LOCALGROUPS from
228 the feed to that site.
232 The I<flags> parameter specifies miscellaneous parameters, including the
233 type of feed, what information should be sent to it, and various
234 limitations on what articles should be sent to a site. They may be
235 specified in any order and should be separated by commas. Flags that take
236 values should have the value immediately after the flag letter with no
237 whitespace. The valid flags are:
241 =item B<E<lt>> I<size>
243 An article will only be sent to this site if it is less than I<size> bytes
244 long. The default is no limit.
246 =item B<E<gt>> I<size>
248 An article will only be sent to this site if it is greater than I<size>
249 bytes long. The default is no limit.
253 An article will only be sent to this site if it meets the requirements
254 specified in I<checks>, which should be chosen from the following set.
255 I<checks> can be multiple letters if appropriate.
261 Exclude all kinds of control messages.
265 Only send control messages, not regular articles.
269 Only send articles with a Distribution header. Combined with a particular
270 distribution value in the I<distribution> part of the site entry, this can
271 be used to limit articles sent to a site to just those with a particuliar
276 Only send articles where every newsgroup listed in the Newsgroups: header
277 exists in the active file.
281 Don't send articles rejected by filters. This is only useful when
282 I<dontrejectfiltered> is set in F<inn.conf>. With that variable set, this
283 lets one accept all articles but not propagate filtered ones to some
288 Only send articles for which overview data was stored.
292 Send articles to this site that don't have an X-Trace: header, even if the
293 C<O> flag is also given.
297 Only check the exclusions against the Path: header of articles; don't
298 check the site name. This is useful if your site names aren't the same as
299 the Path: entries added by those remote sites, or for program feeds where
300 the site name is arbitrary and unrelated to the Path: header.
304 If both C<c> and C<C> are given, the last specified one takes precedence.
306 =item B<B> I<high>/I<low>
308 If a site is being fed by a file, channel, or exploder (see below), the
309 server will normally start trying to write the information as soon as
310 possible. Providing a buffer may give better system performance and help
311 smooth out overall load if a large batch of news comes in. The value of
312 the this flag should be two numbers separated by a slash. I<high>
313 specifies the point at which the server can start draining the feed's I/O
314 buffer, and I<low> specifies when to stop writing and begin buffering
315 again; the units are bytes. The default is to do no buffering, sending
316 output as soon as it is possible to do so.
320 If this flag is specified, an article will only be sent to this site if
321 the number of groups it is posted to, plus the square of the number of
322 groups followups would appear in, is no more than I<count>. C<30> is a
323 good value for this flag, allowing crossposts to up to 29 groups when
324 followups are set to a single group or poster and only allowing crossposts
325 to 5 groups when followups aren't set.
329 Specifies the name of the file that should be used if it's necessary to
330 begin spooling for the site (see below). If I<name> is not an absolute
331 path, it is taken to be relative to I<pathoutgoing> in F<inn.conf>. If
332 I<name> is a directory, the file F<togo> in that directory will be used as
337 If this flag is specified, an article will only be sent to this site if it
338 is posted to no more than I<count> newsgroups. This has the problem of
339 filtering out many FAQs, as well as newsgroup creation postings and
340 similar administrative announcements. Either the B<C> flag or the B<U>
341 flag is a better solution.
345 If this flag is specified, an article will only be sent to this site if it
346 has I<count> or fewer sites in its Path: line. This flag should only be
347 used as a rough guide because of the loose interpretation of the Path:
348 header; some sites put the poster's name in the header, and some sites
349 that might logically be considered to be one hop become two because they
350 put the posting workstation's name in the header. The default value for
351 I<count> if not specified is one. (Also see the B<O> flag, which is
352 sometimes more appropriate for some uses of this flag.)
356 The flag specifies the size of the internal buffer for a file feed. If
357 there are more file feeds than allowed by the system, they will be
358 buffered internally in least-recently-used order. If the internal buffer
359 grows bigger then I<size> bytes, however, the data will be written out to
360 the appropriate file. The default value is 16 KB.
364 Restricts the articles sent to this site to those in newsgroups with the
365 moderation status given by I<status>. If I<status> is C<m>, only articles
366 in moderated groups are sent; if I<status> is C<u>, only articles in
367 unmoderated groups are sent.
369 =item B<O> I<originator>
371 If this flag is specified, an article will only be sent to this site if it
372 contains an X-Trace: header and the first field of this header matches
373 I<originator>. I<originator> is a uwildmat(3) expression without commas or
374 a list of such expressions, separated by C</>. The article is never sent
375 if the first character of the pattern begins with C<@> and the rest of the
376 pattern matches. One use of this flag is to restrict the feed to locally
377 generated posts by using an I<originator> pattern that matches the
378 X-Trace: header added by the local server.
380 =item B<P> I<priority>
382 The nice priority that this channel or program feed should receive. This
383 should be a positive number between 0 and 20 and is the priority that the
384 new process will run with. This flag can be used to raise the priority to
385 normal if you're using the I<nicekids> parameter in F<inn.conf>.
387 =item B<Q> I<hashfeed>
389 Specifies the I<hashfeed> match expression for this site. It must be in
390 the form C<value/mod> or C<start-end/mod>. The Message-ID of the article
391 is hashed using MD5, which results in a 128-bit hash. The lowest
392 S<32 bits> are then taken by default as the hashfeed value (which is an
393 integer). If the hashfeed value modulus C<mod> plus one equals C<value> or
394 is between C<start> and C<end>, the article will be fed to this site. All
395 these numbers must be integers.
397 It is a deterministic way to control the flow of articles and to split a feed.
400 Q1/2 Feeds about 50% of all articles to this site.
401 Q2/2 Feeds the other 50% of all articles.
403 Another example with three sites:
405 Q1-3/10 Feeds about 30% of all articles.
406 Q4-5/10 Feeds about 20% of all articles.
407 Q6-10/10 Feeds about 50% of all articles.
409 If this flag is specified multiple times, the contents will be
410 logically C<OR>ed together (just one match is needed).
412 You can use an extended syntax of the form C<value/mod_offset> or
413 C<start-end/mod_offset>. As MD5 generates a 128-bit return value,
414 it is possible to specify from which byte-offset the 32-bit integer
415 used by hashfeed starts. The default value for C<offset> is C<_0>
416 and thirteen overlapping values from C<_0> to C<_12> can be used.
417 Only up to four totally independent values exist: C<_0>, C<_4>,
420 Therefore, it allows to a generate a second level of deterministic
421 distribution. Indeed, if a news server is fed C<Q1/2>, it can go on
422 splitting thanks to C<Q1-3/9_4> for instance.
424 The algorithm is compatible with the one used by S<Diablo 5.1> and up.
425 If you want to use the legacy quickhashing method used by Diablo
426 before 5.1, you can put an C<@> sign just after the B<Q> flag (for
427 instance C<Q@1-3/10>, but the distribution of the messages is not
428 perfect with this legacy method whose use is discouraged and for
429 which offsets cannot be used).
433 If the amount of data queued for the site gets to be larger than I<size>
434 bytes, the server will switch to spooling, appending to a file specified
435 by the B<F> flag, or I<pathoutgoing>/I<sitename> if B<F> is not specified.
436 Spooling usually happens only for channel or exploder feeds, when the
437 spawned program isn't keeping up with its input.
441 This flag specifies the type of feed for this site. I<type> should be a
442 letter chosen from the following set:
447 m Funnel (multiple entries feed into one)
451 Each feed is described below in L<"FEED TYPES">. The default is B<Tf>,
456 If this flag is specified, an article will only be sent to this site if
457 followups to this article would be posted to no more than I<count>
458 newsgroups. (Also see B<C> for a more complex way of handling this.)
462 For a file, channel, or exploder feed, this flag controls what information
463 will be sent to this site. For a program feed, only the asterisk (C<*>)
464 has any effect. I<items> should be chosen from the following set:
470 Size of the article (in wire format, meaning with CRLF at the end of each
471 line, periods doubled at the beginning of lines, and ending in a line with
472 a single period) in bytes.
476 The time the article will expire as seconds since epoch if it has an
477 Expires: header, C<0> otherwise.
481 The storage API token of the article (the same as C<n>). The article can
482 be retrieved given the storage API token by using sm(8).
486 The newsgroup the article is in; if cross-posted, then the first of the
487 groups to which the article was posted that this site gets. (The
488 difference from C<G> is that this sends the newsgroup to which the article
489 was posted even if it is a control message.)
493 The history hash key of the article (derived from the message ID).
497 The message ID of the article.
501 The storage API token of the article. The article can be retrieved given
502 the storage API token by using sm(8).
506 The time the article was posted a seconds since epoch.
510 The site that fed the article to the server. This is taken from either
511 the Path: header or the IP address of the sending site depending on the
512 value of I<logipaddr> in F<inn.conf>. If I<logipaddr> is true and the IP
513 address is C<0.0.0.0> (meaning that the article was fed from localhost by
514 a program like rnews(8)), the Path: header value will be sent instead.
518 The time the article was received as seconds since epoch.
522 The names of the appropriate funnel entries, or all sites that get the
523 article (see below for more details).
527 The value of the Distribution: header of the article, or C<?> if there is
528 no such header in the article.
532 Where the article is stored. If the newsgroup is crossposted, this is
533 generally the first of the groups to which it was posted that this site
534 receives; however, control messages are filed in control or control.*
535 (which is the difference between this item and C<g>).
539 All of the headers, followed by a blank line. The Xref header will
540 already be present, and a Bytes header containing the article's size in
541 bytes as in the C<b> item will be added to the headers. If used, this
542 should be the only item in the list.
546 The value of the Newsgroups: header.
550 The value of the Path: header.
554 Overview data for the article.
558 Information needed for replication (the Xref header without the site
563 More than one letter can be given. If multiple items are specified, they
564 will be written in the order specified separated by spaces. (C<H> should
565 be the only item if given, but if it's not a newline will be sent before
566 the beginning of the headers.) The default is B<Wn>.
568 The C<H> and C<O> items are intended for use by programs that create news
569 overview databases or require similar information. B<WnteO> is the flag
570 to generate input needed by the overchan(8) program.
572 The asterisk (C<*>) has special meaning. Normally it expands to a
573 space-separated list of all sites that received the current article. If,
574 however, this site is a target of a funnel feed (in other words, if it is
575 named by other sites which have the B<Tm> flag), then the asterisk expands
576 to the names of the funnel feeds that received the article. Similarly, if
577 the site is a program feed, an asterisk in the I<parameter> field will be
578 expanded into the list of funnel feeds that received the article. A
579 program feed cannot get the site list unless it is the target of other
586 B<innd> provides four basic types of feeds: log, file, program, and
587 channel. An exploder is a special type of channel. In addition, several
588 entries can feed into the same feed; these are funnel feeds, which refer
589 to an entry that is one of the other types. Funnel feeds are partially
590 described above with the description of the B<W*> flag. A funnel feed
591 gets every article that would be sent to any of the feeds that funnel into
592 it and normally include the B<W*> flag in their flags so that the program
593 processing that feed knows which sites received which articles. The most
594 common funnel feed is innfeed(8).
596 Note that the term "feed" is technically a misnomer, since the server
597 doesn't transfer articles itself and only writes data to a file, program,
598 or log telling another program to transfer the articles.
600 The simplest feed is a log feed (B<Tl>). Other than a mention in the news
601 log file, I<pathlog>/news, no data is written out. This is equivalent to
602 a B<Tf> entry writing to F</dev/null>, except that no file is ever opened.
603 Flushing a log feed does nothing.
605 A file feed (B<Tf>) is the next simplest type of feed. When the site
606 should receive an article, the specified data is written out to the file
607 named by the I<parameter> field. If I<parameter> is not an absolute path,
608 it is taken to be relative to I<pathoutgoing> in F<inn.conf>. If
609 I<parameter> is not given, it defaults to I<pathoutgoing>/I<sitename>.
610 The file name should be unique (two file feeds should not ever point to
613 File feeds are designed for use by external programs that periodically
614 process the written data. To cooperate with B<innd> properly, such
615 external programs should first rename the batch file and then send a flush
616 command for that site to B<innd> using ctlinnd(8). B<innd> will then
617 write out any buffered data, close the file, and reopen it (under the
618 original name), and the program can process the data in the renamed file
619 at its leisure. File feeds are most frequently used in combination with
622 A program feed (B<Tp>) spawns a given program for every article that the
623 site receives. The I<paramter> field must be the command line to execute,
624 and should contain one instance of C<%s>, which will be replaced by the
625 storage API token of the article (the actual article can be retrieved by
626 the program using sm(8)). The program will not receive anything on
627 standard input (unlike earlier versions of INN, where the article is sent
628 to the program on stdin), and standard output and error from the program
629 will be set to the error log (I<pathlog>/errlog). B<innd> will try to
630 avoid spawning a shell if the command has no shell meta-characters; this
631 feature can be defeated if necessary for some reason by appending a
632 semi-colon to the end of the command. The full path name of the program
633 to be run must be specified unless the command will be run by the shell
634 (and it is strongly recommended that the full path name always be
635 specified regardless).
637 If a program feed is the target of a funnel, and if B<W*> appears in the
638 flags of the site, a single asterisk may be present in the I<parameter>
639 and will be replaced by a space-separated list of names of the sites
640 feeding into the funnel which received the relevant article. If the site
641 is not the target of a funnel, or if the B<W*> flag is not used, the
642 asterisk has no special meaning.
644 Flushing a program feed does nothing.
646 For a channel (B<Tc>) or exploder (B<Tx>) feed, the I<parameter> field
647 again names the process to start. As with program feeds, the full path to
648 the program must be specified. However, rather than spawning the program
649 for every article, it is spawned once and then whenever the site receives
650 an article, the data specified by the site flags is written to the
651 standard input of the spawned program. Standard output and error are set
652 as with program feeds. If the process exits, it will be restarted
653 automatically. If the process cannot be started, the server will spool
654 input to a file named I<pathoutgoing>/I<sitename> and will try to start
655 the process again later.
657 When a channel or exploder feed is flushed, the server closes its end of
658 the pipe to the program's standard input. Any pending data that has not
659 been written will be spooled; see the description of the B<S> flag above.
660 The server will then spawn a new instance of the program. No signal is
661 sent to the program; it is up to the program handling a channel or
662 exploder feed to notice end of file on its standard input and exit
665 Exploders are a special type of channel feed. In addition to the channel
666 feed behavior described above, exploders can also be sent command lines.
667 These lines start with an exclamation point and their interpretation is up
668 to the exploder. The following commands are generated automatically by
676 These commands are sent whenever the ctlinnd(8) command of the same name
677 is received by the server. In addition, the ctlinnd(8) C<send> command
678 can be used to send an arbitrary command line to an exploder. The primary
679 exploder is buffchan(8).
681 Finally, B<Tm> feeds are the input to a funnel. The I<parameter> field of
682 the site should name the site handling articles for all of the funnel
687 All of the following examples assume that INN was installed with a prefix
688 of F</usr/local/news>; if you installed it somewhere else, modify the
689 paths as appropriate.
691 The syntax of the F<newsfeeds> file is so complex because you can specify
692 a staggering variety of feeds. INN is capable of interacting with a wide
693 variety of programs that do various things with news articles. Far and
694 away the most common two entries in F<newsfeeds>, however, are file feeds
695 for nntpsend(8) and funnel feeds for innfeed(8).
697 The former look like this:
699 feed.example.com:*,!control,!control.*,!junk:Tf,Wnm:
701 which generates a file named I<pathoutgoing>/feed.example.com containing
702 one line per article consisting of the storage API token, a space, and the
705 The latter look like this:
707 feed.example.com:*,!control,!control.*,!junk:Tm:innfeed!
709 Very similar, except that this is the input to a funnel feed named
710 C<innfeed!>. One could also write this as:
712 example/feed.example.com:*,!control,!control.*,!junk:Ap,Tm:innfeed!
714 (note the B<Ap> so that articles that contain just C<example> in the Path:
715 header will still be sent), which is completely equivalent except that
716 this will be logged in I<pathlog>/news as going to the site C<example>
717 rather than C<feed.example.com>.
719 The typical feed entry for innfeed(8) is a good example of a channel feed
720 that's the target of various funnel feeds:
722 innfeed!:!*:Tc,Wnm*:/usr/local/news/bin/startinnfeed -y
724 Note that the I<pattern> for this feed is just C<!*> so that it won't
725 receive any articles directly. The feed should only receive those
726 articles that would go to one of the funnel feeds that are feeding into
727 it. innfeed(8) (spawned by B<startinnfeed>) will receive one line per
728 article on its standard input containing the storage API token, the
729 message ID, and a space-separated list of sites that should receive that
732 Here's a more esoteric example of a channel feed:
735 :exec awk '$1 > 1000000 { print "BIG", $2, $3 }' > /dev/console
737 This receives the byte size of each article along with the storage API
738 token and message ID, and prints to the console a line for every article
739 that's over a million bytes. This is actually rather a strange way to
740 write this since INN can do the size check itself; the following is
743 watcher!:*:Tc,>1000000,Wbnm\
744 :exec awk '{ print "BIG", $2, $3}' > /dev/console
746 Here's a cute, really simple news to mail gateway that also serves as an
747 example of a fairly fancy program feed:
750 :sm %s | innmail -s "News article" *
752 Remember that C<%s> is replaced by the storage API token, so this
753 retrieves the article and pipes it into B<innmail> (which is safer than
754 programs like Mail(1) because it doesn't parse the body for tilde
755 commands) with a given subject line. Note the use of C<*> in the command
756 line and B<W*> in the flags; this entry is designed to be used as the
757 target of funnel feeds such as:
759 peter@example.com:news.software.nntp:Tm:mailer!
760 sue@example.com:news.admin.misc:Tm:mailer!
762 Suppose that the server receives an article crossposted between
763 news.admin.misc and news.software.nntp. The server will notice that the
764 article should be sent to the site C<peter@example.com> and the site
765 C<bob@example.com>, both of which funnel into C<mailer!>, so it will look
766 at the C<mailer!> site and end up executing the command line:
768 sm @...@ | innmail -s "News article" peter@example.com sue@example.com
770 which will mail the article to both Peter and Sue.
772 Finally, another very useful example of a channel feed: the standard
773 entry for controlchan(8).
776 :!*,control,control.*,!control.cancel/!collabra-internal\
777 :Tc,Wnsm:/usr/local/news/bin/controlchan
779 This program only wants information about articles posted to a control
780 newsgroup other than control.cancel, which due to the sorting of control
781 messages described in innd(8) will send it all control messages except for
782 cancel messages. In this case, we also exclude any article with a
783 distribution of C<collabra-internal>. B<controlchan> gets the storage
784 API token, the name of the sending site (for processing old-style ihave
785 and sendme control messages, be sure to read about I<logipaddr> in
786 controlchan(8)), and the message ID for each article.
788 For many other examples, including examples of the special C<ME> site
789 entry, see the example F<newsfeeds> file distributed with INN. Also see the
790 install documentation that comes with INN for information about setting up
791 the standard newsfeeds entries used by most sites.
795 Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Reformatted
796 and rewritten in POD by Russ Allbery <rra@stanford.edu>.
798 $Id: newsfeeds.pod 7741 2008-04-06 09:51:47Z iulius $
802 active(5), buffchan(8), controlchan(8), ctlinnd(8), inn.conf(5), innd(8),
803 innfeed(8), innxmit(8), nntpsend(8), uwildmat(3).
~ian / inn-innduct.git / blob