1NEWSFEEDS(5) InterNetNews Documentation NEWSFEEDS(5)
2
6 newsfeeds - Determine where Usenet articles are sent
7
9 The file pathetc/newsfeeds specifies how incoming articles should be
10 distributed to other programs and files on the server. It is parsed by
11 the InterNetNews server innd(8) when it starts up, or when directed to
12 by ctlinnd(8). innd doesn't send articles to remote sites itself, so
13 newsfeeds doesn't directly determine which remote news servers articles
14 are sent to. Instead, it specifies what batch files should be created
15 or which programs should be run (and what information should be sent to
16 them), and then this information is used by programs like innxmit(8)
17 and innfeed(8) to feed articles to remote sites.
18 The newsfeeds file isn't used solely to set up feeding accepted arti‐
20 cles to remote sites but also to pass them (or bits of information
21 about them) to any local programs or files that want that data. For
22 example, controlchan(8), a daemon that processes incoming control mes‐
23 sages, runs out of newsfeeds, as could a news to mail gateway.
24 The file is interpreted as a set of lines, parsed according to the fol‐
26 lowing rules: If a line ends with a backslash, the backslash, the new‐
27 line, and any whitespace at the start of the next line is deleted.
28 This is repeated until the entire "logical" line is collected. If the
29 logical line is blank or starts with a number sign ("#"), it is
30 ignored.
31 All other lines are interpreted as feed entries. An entry should con‐
33 sist of four colon-separated fields; two of the fields may have
34 optional sub-fields, marked off by a slash. Fields or sub-fields that
35 take multiple parameters should be separated by a comma. Extra white‐
36 space can cause problems and should be avoided. Except for the site
37 names, case is significant. The format of an entry is:
38 sitename[/exclude,exclude,...]\
40 :pattern,pattern...[/distribution,distribution...]\
41 :flag,flag...\
42 :parameter
43 Each field is described below.
45 The sitename is the name of the site to which a news article can be
47 sent. It is used for writing log entries and for determining if an
48 article should be forwarded to a site. (A "site" is the generic term
49 for some destination of newsfeed data; it often corresponds to a remote
50 news peer, but doesn't have to. For example, a local archiving program
51 run from newsfeeds is also a "site.") If sitename already appears in
52 the article's Path: header, then the article will not be sent to the
53 site. The name is usually whatever the remote site uses to identify
54 itself in the Path: header, but can be almost any word.
55 Be careful, though, to avoid having the sitename accidentally match a
57 Path: header entry unintentionally. For this reason, special local
58 entries (such as archivers or gateways) should probably end with an
59 exclamation point to make sure that they do not have the same name as
60 any real site. For example, "gateway" is an obvious name for the local
61 entry that forwards articles out to a mailing list. If a site with the
62 name "gateway" posts an article, when the local site receives the arti‐
63 cle it will see the name in the Path and not send the article to its
64 own "gateway" entry. Since "gateway!" can't appear as an individual
65 Path: entry since "!" is a delimiter in the Path: header, that would be
66 a better thing to use for sitename.
67 (Another way to avoid this problem is with the "Ap" flag; see the
69 description below.)
70 If an entry has an exclusion sub-field, the article will not be sent to
72 that site if any of exclude appear in the Path: header. (It's some‐
73 times convenient to have the sitename be an abbreviated form of the
74 name of the remote site, since all the sitenames to which an article is
75 sent are written to the log and using shorter sitenames can therefore
76 improve performance for large servers. In this case, the Path: header
77 entries of those sites should be given as exclude entries and the "Ap"
78 flag used so that the abbreviated sitename doesn't accidentally match
79 some other Path: header entry.)
80 The same sitename can be used more than once and the appropriate action
82 will be taken for each entry that should receive the article, but this
83 is recommended only for program feeds to avoid confusion. Case is not
84 significant in site names.
85 The comma-separated pattern specifies which groups to send to the site;
87 it is interpreted to build a "subscription list" for the site. The
88 default subscription is to get all groups carried by the server. It is
89 a uwildmat(3) pattern supporting poison ("@") wildcards; see the uwild‐
90 mat(3) man page for full details on the pattern matching language.
91 pattern will be matched against every newsgroup carried by the server
92 and all newsgroups that match will be added to the subscription list
93 for the site.
94 Normally, a given article (or information about it) is sent to a site
96 if any of the newsgroups to which the article was posted are in that
97 site's subscription list. If a newsgroup matches a "@" pattern in pat‐
98 tern, then not only is it not added to the subscription list, but any
99 articles crossposted to that newsgroup also will not be sent to that
100 site even if other newsgroups to which it was crossposted are in that
101 site's subscription list. This is called a poison pattern (because
102 matching groups are "poisoned").
103 For example, to receive all comp.* groups, but only comp.sources.unix
105 within the sources newsgroups, the following pattern can be used:
106 comp.*,!comp.sources.*,comp.sources.unix
108 Note that the trailing ".*" is required; the pattern has to match the
110 whole newsgroup name. "comp.sources.*" could be written
111 "comp.sources*" and would exclude the newsgroup comp.sources (if it
112 exists) as well as the groups in the comp.sources.* hierarchy, but note
113 that this would also exclude a newsgroup named comp.sources-only
114 (whereas the above pattern would add that group to the site subscrip‐
115 tion list since it matches "comp.*" and none of the other patterns.
116 For another example, to feed alt.* and misc.* to a given site but not
118 any articles posted to alt.binaries.warez (even if they're also cross‐
119 posted to other alt.* or misc.* groups), the following pattern can be
120 used:
121 alt.*,@alt.binaries.warez,misc.*
123 Note, however, that if you reversed the "alt.*" and <@alt.bina‐
125 ries.warez> entries, this pattern would be equivalent to
126 "alt.*,misc.*", since the last matching pattern determines whether a
127 given newsgroup matches and the poison logic only applies if the poison
128 entry is the last matching entry.
129 Control messages follow slightly different propagation rules than nor‐
131 mal articles; see innd(8) for the details. Note that most subscrip‐
132 tions should have "!junk,!control*" in their pattern list due to those
133 propagation rules (and since junk is a special internal newsgroup; see
134 wanttrash in inn.conf(5) for more details on what it's used for).
135 A subscription can be further modified by specifying distributions that
137 the site should or should not receive. The default is to send all
138 articles to all sites that subscribe to any of the groups where it has
139 been posted, but if an article has a Distribution: header and any dis‐
140 tributions are specified, then they are checked according to the fol‐
141 lowing rules:
142 1. If the Distribution: header matches any of the values in the
144 sub-field, the article is sent.
145 2. If a distribution starts with an exclamation point, and it matches
147 the Distribution: header, the article is not sent.
148 3. If the Distribution: header does not match any distribution in the
150 site's entry and no negations were used, the article is not sent.
151 4. If the Distribution: header does not match any distribution in the
153 site's entry and any distribution started with an exclamation
154 point, the article is sent.
155 If an article has more than one distribution specified, then each one
157 is handled according according to the above rules. If any of the spec‐
158 ified distributions indicate that the article should be sent, it is; if
159 none do, it is not sent. In other words, the rules are used as a logi‐
160 cal or.
161 It is almost definitely a mistake to have a single feed that specifies
163 distributions that start with an exclamation point along with some that
164 don't.
165 Distributions are text words, not patterns; entries like "*" or "all"
167 have no special meaning.
168 The flag field is described in "FLAG VALUES". The interpretation of
170 the parameter field depends on the type of feed and is explained in
171 more detail in "FEED TYPES". It can be omitted for some types of
172 feeds.
173 The site named "ME" is special. There must be exactly one such entry,
175 and it should be the first entry in the file. If the "ME" entry has an
176 exclusion sub-field, incoming articles are rejected completely if any
177 of the names specified in that exclusion sub-field appear in their
178 Path: headers. If the "ME" entry has a subscription list, that list is
179 prepended to the subscription list of all other entries. For example,
180 "*,!control*,!junk,!foo.*" could be used to set the default subscrip‐
181 tion list for all other feeds so that local postings are not propagated
182 unless "foo.*" explicitly appears in the site's subscription list.
183 This feature tends to be somewhat confusing since the default subscrip‐
184 tion is prepended and can be overridden by other patterns.
185 If the "ME" entry has a distribution sub-field, only articles that
187 match that distribution list are accepted and all other articles are
188 rejected. A common use for this is to put something like "/!local" in
189 the "ME" entry to reject local postings from other misconfigured sites.
190 Finally, it is also possible to set variables in newsfeeds and use them
192 later in the file. A line starting with "$" sets a variable. For
193 example:
194 $LOCALGROUPS=local.*,example.*
196 This sets the variable "LOCALGROUPS" to "local.*,example.*". This
198 variable can later be used elsewhere in the file, such as in a site
199 entry like:
200 news.example.com:$LOCALGROUPS:Tf,Wnm:
202 which is then completely equivalent to:
204 news.example.com:local.*,example.*:Tf,Wnm:
206 Variables aren't solely simple substitution. If either "!" or "@"
208 immediately preceeds the variable and the value of the variable con‐
209 tains commas, that character will be duplicated before each comma.
210 This somewhat odd-sounding behavior is designed to make it easier to
211 use variables to construct feed patterns. The utility becomes more
212 obvious when you observe that the line:
213 news.example.net:*,@$LOCALGROUPS:Tf,Wnm:
215 is therefore equivalent to:
217 news.example.net:*,@local.*,@example.*:Tf,Wnm:
219 which (as explained below) excludes all of the groups in $LOCALGROUPS
221 from the feed to that site.
222
224 The flags parameter specifies miscellaneous parameters, including the
225 type of feed, what information should be sent to it, and various limi‐
226 tations on what articles should be sent to a site. They may be speci‐
227 fied in any order and should be separated by commas. Flags that take
228 values should have the value immediately after the flag letter with no
229 whitespace. The valid flags are:
230 < size
232 An article will only be sent to this site if it is less than size
233 bytes long. The default is no limit.
234 > size
236 An article will only be sent to this site if it is greater than
237 size bytes long. The default is no limit.
238 A checks
240 An article will only be sent to this site if it meets the require‐
241 ments specified in checks, which should be chosen from the follow‐
242 ing set. checks can be multiple letters if appropriate.
243 c Exclude all kinds of control messages.
245 C Only send control messages, not regular articles.
247 d Only send articles with a Distribution header. Combined with a
249 particular distribution value in the distribution part of the
250 site entry, this can be used to limit articles sent to a site to
251 just those with a particuliar distribution.
252 e Only send articles where every newsgroup listed in the News‐
254 groups: header exists in the active file.
255 f Don't send articles rejected by filters. This is only useful
257 when dontrejectfiltered is set in inn.conf. With that variable
258 set, this lets one accept all articles but not propagate fil‐
259 tered ones to some sites.
260 o Only send articles for which overview data was stored.
262 O Send articles to this site that don't have an X-Trace: header,
264 even if the "O" flag is also given.
265 p Only check the exclusions against the Path: header of articles;
267 don't check the site name. This is useful if your site names
268 aren't the same as the Path: entries added by those remote
269 sites, or for program feeds where the site name is arbitrary and
270 unrelated to the Path: header.
271 If both "c" and "C" are given, the last specified one takes prece‐
273 dence.
274 B high/low
276 If a site is being fed by a file, channel, or exploder (see below),
277 the server will normally start trying to write the information as
278 soon as possible. Providing a buffer may give better system per‐
279 formance and help smooth out overall load if a large batch of news
280 comes in. The value of the this flag should be two numbers sepa‐
281 rated by a slash. high specifies the point at which the server can
282 start draining the feed's I/O buffer, and low specifies when to
283 stop writing and begin buffering again; the units are bytes. The
284 default is to do no buffering, sending output as soon as it is pos‐
285 sible to do so.
286 C count
288 If this flag is specified, an article will only be sent to this
289 site if the number of groups it is posted to, plus the square of
290 the number of groups followups would appear in, is no more than
291 count. 30 is a good value for this flag, allowing crossposts to up
292 to 29 groups when followups are set to a single group or poster and
293 only allowing crossposts to 5 groups when followups aren't set.
294 F name
296 Specifies the name of the file that should be used if it's neces‐
297 sary to begin spooling for the site (see below). If name is not an
298 absolute path, it is taken to be relative to pathoutgoing in
299 inn.conf. If name is a directory, the file togo in that directory
300 will be used as the file name.
301 G count
303 If this flag is specified, an article will only be sent to this
304 site if it is posted to no more than count newsgroups. This has
305 the problem of filtering out many FAQs, as well as newsgroup cre‐
306 ation postings and similar administrative announcements. Either
307 the C flag or the U flag is a better solution.
308 H count
310 If this flag is specified, an article will only be sent to this
311 site if it has count or fewer sites in its Path: line. This flag
312 should only be used as a rough guide because of the loose interpre‐
313 tation of the Path: header; some sites put the poster's name in the
314 header, and some sites that might logically be considered to be one
315 hop become two because they put the posting workstation's name in
316 the header. The default value for count if not specified is one.
317 (Also see the O flag, which is sometimes more appropriate for some
318 uses of this flag.)
319 I size
321 The flag specifies the size of the internal buffer for a file feed.
322 If there are more file feeds than allowed by the system, they will
323 be buffered internally in least-recently-used order. If the inter‐
324 nal buffer grows bigger then size bytes, however, the data will be
325 written out to the appropriate file. The default value is 16 KB.
326 N status
328 Restricts the articles sent to this site to those in newsgroups
329 with the moderation status given by status. If status is "m", only
330 articles in moderated groups are sent; if status is "u", only arti‐
331 cles in unmoderated groups are sent.
332 O originator
334 If this flag is specified, an article will only be sent to this
335 site if it contains an X-Trace: header and the first field of this
336 header matches originator. originator is a uwildmat(3) expression
337 without commas or a list of such expressions, separated by "/".
338 The article is never sent if the first character of the pattern
339 begins with "@" and the rest of the pattern matches. One use of
340 this flag is to restrict the feed to locally generated posts by
341 using an originator pattern that matches the X-Trace: header added
342 by the local server.
343 P priority
345 The nice priority that this channel or program feed should receive.
346 This should be a positive number between 0 and 20 and is the prior‐
347 ity that the new process will run with. This flag can be used to
348 raise the priority to normal if you're using the nicekids parameter
349 in inn.conf.
350 S size
352 If the amount of data queued for the site gets to be larger than
353 size bytes, the server will switch to spooling, appending to a file
354 specified by the F flag, or pathoutgoing/sitename if F is not spec‐
355 ified. Spooling usually happens only for channel or exploder
356 feeds, when the spawned program isn't keeping up with its input.
357 T type
359 This flag specifies the type of feed for this site. type should be
360 a letter chosen from the following set:
361 c Channel
363 f File
364 l Log entry only
365 m Funnel (multiple entries feed into one)
366 p Program
367 x Exploder
368 Each feed is described below in "FEED TYPES". The default is Tf,
370 for a file feed.
371 U count
373 If this flag is specified, an article will only be sent to this
374 site if followups to this article would be posted to no more than
375 count newsgroups. (Also see C for a more complex way of handling
376 this.)
377 W items
379 For a file, channel, or exploder feed, this flag controls what
380 information will be sent to this site. For a program feed, only
381 the asterisk ("*") has any effect. items should be chosen from the
382 following set:
383 b Size of the article (in wire format, meaning with CRLF at the
385 end of each line, periods doubled at the beginning of lines, and
386 ending in a line with a single period) in bytes.
387 e The time the article will expire as seconds since epoch if it
389 has an Expires: header, 0 otherwise.
390 f The storage API token of the article (the same as "n"). The
392 article can be retrieved given the storage API token by using
393 sm(8).
394 g The newsgroup the article is in; if cross-posted, then the first
396 of the groups to which the article was posted that this site
397 gets. (The difference from "G" is that this sends the newsgroup
398 to which the article was posted even if it's a control message.)
399 h The history hash key of the article (derived from the message
401 ID).
402 m The message ID of the article.
404 n The storage API token of the article. The article can be
406 retrieved given the storage API token by using sm(8).
407 p The time the article was posted a seconds since epoch.
409 s The site that fed the article to the server. This is taken from
411 either the Path: header or the IP address of the sending site
412 depending on the value of logipaddr in inn.conf. If logipaddr
413 is true and the IP address is 0.0.0.0 (meaning that the article
414 was fed from localhost by a program like rnews(8)), the Path:
415 header value will be sent instead.
416 t The time the article was received as seconds since epoch.
418 * The names of the appropriate funnel entries, or all sites that
420 get the article (see below for more details).
421 D The value of the Distribution: header of the article, or "?" if
423 there is no such header in the article.
424 G Where the article is stored. If the newsgroup is crossposted,
426 this is generally the first of the groups to which it was posted
427 that this site receives; however, control messages are filed in
428 control or control.* (which is the difference between this item
429 and "g").
430 H All of the headers, followed by a blank line. The Xref header
432 will already be present, and a Bytes header containing the arti‐
433 cle's size in bytes as in the "b" item will be added to the
434 headers. If used, this should be the only item in the list.
435 N The value of the Newsgroups: header.
437 P The value of the Path: header.
439 O Overview data for the article.
441 R Information needed for replication (the Xref header without the
443 site name).
444 More than one letter can be given. If multiple items are speci‐
446 fied, they will be written in the order specified separated by spa‐
447 ces. ("H" should be the only item if given, but if it's not a new‐
448 line will be sent before the beginning of the headers.) The
449 default is Wn.
450 The "H" and "O" items are intended for use by programs that create
452 news overview databases or require similar information. WnteO is
453 the flag to generate input needed by the overchan(8) program.
454 The asterisk ("*") has special meaning. Normally it expands to a
456 space-separated list of all sites that received the current arti‐
457 cle. If, however, this site is a target of a funnel feed (in other
458 words, if it is named by other sites which have the Tm flag), then
459 the asterisk expands to the names of the funnel feeds that received
460 the article. Similarly, if the site is a program feed, an asterisk
461 in the parameter field will be expanded into the list of funnel
462 feeds that received the article. A program feed cannot get the
463 site list unless it is the target of other Tm feeds.
464
466 innd provides four basic types of feeds: log, file, program, and chan‐
467 nel. An exploder is a special type of channel. In addition, several
468 entries can feed into the same feed; these are funnel feeds, which
469 refer to an entry that is one of the other types. Funnel feeds are
470 partially described above with the description of the W* flag. A fun‐
471 nel feed gets every article that would be sent to any of the feeds that
472 funnel into it and normally include the W* flag in their flags so that
473 the program processing that feed knows which sites received which arti‐
474 cles. The most common funnel feed is innfeed(8).
475 Note that the term "feed" is technically a misnomer, since the server
477 doesn't transfer articles itself and only writes data to a file, pro‐
478 gram, or log telling another program to transfer the articles.
479 The simplest feed is a log feed (Tl). Other than a mention in the news
481 log file, pathlog/news, no data is written out. This is equivalent to
482 a Tf entry writing to /dev/null, except that no file is ever opened.
483 Flushing a log feed does nothing.
484 A file feed (Tf) is the next simplest type of feed. When the site
486 should receive an article, the specified data is written out to the
487 file named by the parameter field. If parameter is not an absolute
488 path, it is taken to be relative to pathoutgoing in inn.conf. If
489 parameter is not given, it defaults to pathoutgoing/sitename. The file
490 name should be unique (two file feeds should not ever point to the same
491 file).
492 File feeds are designed for use by external programs that periodically
494 process the written data. To cooperate with innd properly, such exter‐
495 nal programs should first rename the batch file and then send a flush
496 command for that site to innd using ctlinnd(8). innd will then write
497 out any buffered data, close the file, and reopen it (under the origi‐
498 nal name), and the program can process the data in the renamed file at
499 its leisure. File feeds are most frequently used in combination with
500 nntpsend(8).
501 A program feed (Tp) spawns a given program for every article that the
503 site receives. The paramter field must be the command line to execute,
504 and should contain one instance of %s, which will be replaced by the
505 storage API token of the article (the actual article can be retrieved
506 by the program using sm(8)). The program will not receive anything on
507 standard input (unlike earlier versions of INN, where the article is
508 sent to the program on stdin), and standard output and error from the
509 program will be set to the error log (pathlog/errlog). innd will try
510 to avoid spawning a shell if the command has no shell meta-characters;
511 this feature can be defeated if necessary for some reason by appending
512 a semi-colon to the end of the command. The full path name of the pro‐
513 gram to be run must be specified unless the command will be run by the
514 shell (and it is strongly recommended that the full path name always be
515 specified regardless).
516 If a program feed is the target of a funnel, and if W* appears in the
518 flags of the site, a single asterisk may be present in the parameter
519 and will be replaced by a space-separated list of names of the sites
520 feeding into the funnel which received the relevant article. If the
521 site is not the target of a funnel, or if the W* flag is not used, the
522 asterisk has no special meaning.
523 Flushing a program feed does nothing.
525 For a channel (Tc) or exploder (Tx) feed, the parameter field again
527 names the process to start. As with program feeds, the full path to
528 the program must be specified. However, rather than spawning the pro‐
529 gram for every article, it is spawned once and then whenever the site
530 receives an article, the data specified by the site flags is written to
531 the standard input of the spawned program. Standard output and error
532 are set as with program feeds. If the process exits, it will be
533 restarted automatically. If the process cannot be started, the server
534 will spool input to a file named pathoutgoing/sitename and will try to
535 start the process again later.
536 When a channel or exploder feed is flushed, the server closes its end
538 of the pipe to the program's standard input. Any pending data that has
539 not been written will be spooled; see the description of the S flag
540 above. The server will then spawn a new instance of the program. No
541 signal is sent to the program; it is up to the program handling a chan‐
542 nel or exploder feed to notice end of file on its standard input and
543 exit appropriately.
544 Exploders are a special type of channel feed. In addition to the chan‐
546 nel feed behavior described above, exploders can also be sent command
547 lines. These lines start with an exclamation point and their interpre‐
548 tation is up to the exploder. The following commands are generated
549 automatically by the server:
550 !newgroup group
552 !rmgroup group
553 !flush
554 !flush site
555 These commands are sent whenever the ctlinnd(8) command of the same
557 name is received by the server. In addition, the ctlinnd(8) "send"
558 command can be used to send an arbitrary command line to an exploder.
559 The primary exploder is buffchan(8).
560 Finally, Tm feeds are the input to a funnel. The parameter field of
562 the site should name the site handling articles for all of the funnel
563 inputs.
564
566 All of the following examples assume that INN was installed with a pre‐
567 fix of /usr/local/news; if you installed it somewhere else, modify the
568 paths as appropriate.
569 The syntax of the newsfeeds file is so complex because you can specify
571 a staggering variety of feeds. INN is capable of interacting with a
572 wide variety of programs that do various things with news articles.
573 Far and away the most common two entries in newsfeeds, however, are
574 file feeds for nntpsend(8) and funnel feeds for innfeed(8).
575 The former look like this:
577 feed.example.com:*,!control*,!junk:Tf,Wnm:
579 which generates a file named pathoutgoing/feed.example.com containing
581 one line per article consisting of the storage API token, a space, and
582 the message ID.
583 The latter look like this:
585 feed.example.com:*,!control*,!junk:Tm:innfeed!
587 Very similar, except that this is the input to a funnel feed named
589 "innfeed!". One could also write this as:
590 example/feed.example.com:*,!control*,!junk:Ap,Tm:innfeed!
592 (note the Ap so that articles that contain just "example" in the Path:
594 header will still be sent), which is completely equivalent except that
595 this will be logged in pathlog/news as going to the site "example"
596 rather than "feed.example.com".
597 The typical feed entry for innfeed(8) is a good example of a channel
599 feed that's the target of various funnel feeds:
600 innfeed!:!*:Tc,Wnm*:/usr/local/news/bin/startinnfeed -y
602 Note that the pattern for this feed is just "!*" so that it won't
604 receive any articles directly. The feed should only receive those
605 articles that would go to one of the funnel feeds that are feeding into
606 it. innfeed(8) (spawned by startinnfeed) will receive one line per
607 article on its standard input containing the storage API token, the
608 message ID, and a space-separated list of sites that should receive
609 that article.
610 Here's a more esoteric example of a channel feed:
612 watcher!:*:Tc,Wbnm\
614 :exec awk '$1 > 1000000 { print "BIG", $2, $3 }' > /dev/console
615 This receives the byte size of each article along with the storage API
617 token and message ID, and prints to the console a line for every arti‐
618 cle that's over a million bytes. This is actually rather a strange way
619 to write this since INN can do the size check itself; the following is
620 equivalent:
621 watcher!:*:Tc,>1000000,Wbnm\
623 :exec awk '{ print "BIG", $2, $3}' > /dev/console
624 Here's a cute, really simple news to mail gateway that also serves as
626 an example of a fairly fancy program feed:
627 mailer!:!*:W*,Tp\
629 :sm %s ⎪ innmail -s "News article" *
630 Remember that %s is replaced by the storage API token, so this
632 retrieves the article and pipes it into innmail (which is safer than
633 programs like Mail(1) because it doesn't parse the body for tilde com‐
634 mands) with a given subject line. Note the use of "*" in the command
635 line and W* in the flags; this entry is designed to be used as the tar‐
636 get of funnel feeds such as:
637 peter@example.com:news.software.nntp:Tm:mailer!
639 sue@example.com:news.admin.misc:Tm:mailer!
640 Suppose that the server receives an article crossposted between
642 news.admin.misc and news.software.nntp. The server will notice that
643 the article should be sent to the site "peter@example.com" and the site
644 "bob@example.com", both of which funnel into "mailer!", so it will look
645 at the "mailer!" site and end up executing the command line:
646 sm @...@ ⎪ innmail -s "News article" peter@example.com sue@example.com
648 which will mail the article to both Peter and Sue.
650 Finally, another very useful example of a channel feed: the standard
652 entry for controlchan(8).
653 controlchan!\
655 :!*,control,control.*,!control.cancel/!collabra-internal\
656 :Tc,Wnsm:/usr/local/news/bin/controlchan
657 This program only wants information about articles posted to a control
659 newsgroup other than control.cancel, which due to the sorting of con‐
660 trol messages described in innd(8) will send it all control messages
661 except for cancel messages provided that control.cancel exists. In
662 this case, we also exclude any article with a distribution of "col‐
663 labra-internal". controlchan gets the storage API token, the name of
664 the sending site (for processing old-style ihave and sendme control
665 messages, be sure to read about logipaddr in controlchan(8)), and the
666 message ID for each article.
667 For many other examples, including examples of the special "ME" site
669 entry, see the example newsfeeds file distributed with INN. Also see
670 the install documentation that comes with INN for information about
671 setting up the standard newsfeeds entries used by most sites.
672
674 Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Reformat‐
675 ted and rewritten in POD by Russ Allbery <rra@stanford.edu>.
676 $Id: newsfeeds.5 7134 2005-03-05 21:19:44Z vinocur $
678
680 active(5), buffchan(8), controlchan(8), ctlinnd(8), inn.conf(5),
681 innd(8), innfeed(8), innxmit(8), nntpsend(8), uwildmat(3).
682INN 2.4.3 2005-02-26 NEWSFEEDS(5)