1CONTROL.CTL(5) InterNetNews Documentation CONTROL.CTL(5)
2
6 control.ctl - Specify handling of Usenet control messages
7
9 control.ctl in pathetc is used to determine what action is taken when a
10 control message is received. It is read by controlchan, which is nor‐
11 mally invoked as a channel program by innd. When control.ctl is modi‐
12 fied, controlchan notices this automatically and reloads it.
13 Blank lines and lines beginning with a number sign ("#") are ignored.
15 All other lines should consist of four fields separated by colons:
16 <type>:<from>:<newsgroups>:<action>
18 The first field, <type>, is the type of control message for which this
20 line is valid. It should either be the name of a control message or
21 the word "all" to indicate that it applies to all control messages.
22 The second field, <from>, is a shell-style pattern that matches the
24 e-mail address of the person posting the message (with the address
25 first converted to lowercase). The matching is done with rules equiva‐
26 lent to those of the shell's case statement; see sh(1) for more
27 details.
28 If the control message is a newgroup or rmgroup, the third field,
30 <newsgroups>, is a shell-style pattern matching the newsgroup affected
31 by the control message. If the control message is a checkgroups, the
32 third field is a shell-style pattern matching the newsgroups that
33 should be processed for checking. If the control message is of any
34 other type, the third field is ignored.
35 The fourth field, <action>, specifies what action to take with control
37 messages that match this line. The following actions are understood:
38 doit
40 The action requested by the control message should be performed.
41 In some cases, the control script will also send mail to the news
42 administrator (the argument to --with-news-master given at config‐
43 ure time, "usenet" by default), but if notification of the action
44 should always be sent, use "doit=mail" instead (see below).
45 doifarg
47 If the control message has an argument, this is equivalent to doit.
48 If it does not have an argument, this is equivalent to mail. This
49 is only useful for entries for sendsys control messages, allowing a
50 site to request its own newsfeeds entry by posting a "sendsys
51 mysite" control message, but not allowing the entire newsfeeds file
52 to be sent. This was intended to partially counter so-called
53 "sendsys bombs," where forged sendsys control messages were used to
54 mailbomb people.
55 Processing sendsys control messages is not recommended even with
57 this work-around unless they are authenticated in some fashion.
58 The risk of having news servers turned into anonymous mail bombing
59 services is too high.
60 doit=file
62 The action is performed as in doit, and additionally a log entry is
63 written to the specified log file file. If file is the word
64 "mail", the log entry is mailed to the news administrator instead.
65 An empty string is equivalent to /dev/null and says to log nothing.
66 If file starts with a slash, it is taken as the absolute filename
68 to use for the log file. Otherwise, the filename is formed by
69 prepending pathlog and a slash and appending ".log". In other
70 words, an action of "doit=newgroup" will log to pathlog/new‐
71 group.log.
72 drop
74 No action is taken and the message is ignored.
75 verify-*
77 If the action starts with the string "verify-", as in:
78 verify-news.announce.newgroups
80 then PGP verification of the control message will be done and the
82 user ID of the key of the authenticated signer will be checked
83 against the expected identity defined by the rest of the string
84 ("news.announce.newgroups" in the above example. This verification
85 is done via pgpverify; see pgpverify(8) for more details.
86 If no logging is specified (with =file as mentioned below), notifi‐
88 cation of successful newgroup and rmgroup control messages and the
89 output of checkgroups messages will be mailed to the news adminis‐
90 trator.
91 verify-*=file
93 PGP verification is done as for the verify-* action described
94 above, and a log entry is written to the specified file as
95 described in doit=file above. (In the case of checkgroups mes‐
96 sages, this means that the shell script output of the checkgroups
97 message will be written to that file.)
98 log A one-line log message is sent to standard error. innd normally
100 directs this to pathlog/errlog.
101 log=file
103 A log entry is written to the specified log file, which is inter‐
104 preted as in doit=file described above.
105 mail
107 A mail message is sent to the news administrator.
108 Processing of a checkgroups message will never actually change the
110 active file (the list of groups carried by the server). The difference
111 between a doit or verify action and a mail action for a checkgroups
112 control message lies only in what e-mail is sent; doit or verify will
113 mail the news administrator a shell script to create, delete, or modify
114 newsgroups to match the checkgroups message, whereas mail will just
115 mail the entire message. In either case, the news administrator will
116 have to take action to implement the checkgroups message, and if that
117 mail is ignored, nothing will be changed.
118 Lines are matched in order and the last matching line in the file will
120 be used.
121 Use of the verify action for processing newgroup, rmgroup, and check‐
123 groups messages is STRONGLY recommended. Abuse of control messages is
124 rampant, and authentication via PGP signature is currently the only
125 reliable way to be sure that a control message comes from who it claims
126 to be from. Most major hierarchies are now issuing PGP-authenticated
127 control messages.
128 In order to use verify actions, the PGP key ring of the news user must
130 be populated with the PGP keys of the hierarchy maintainers whose con‐
131 trol messages you want to honor. For more details on PGP-authenticated
132 control messages and the URL for downloading the PGP keys of major
133 hierarchies, see pgpverify(8).
134 Control messages of type cancel are handled internally by innd and can‐
136 not be affected by any of the mechanisms described here.
137
139 With the following three lines in control.ctl:
140 newgroup:*:*:drop
142 newgroup:group-admin@isc.org:comp.*:verify-news.announce.newgroups
143 newgroup:kre@munnari.oz.au:aus.*:mail
144 a newgroup coming from "group-admin@isc.org" will be honored if it is
146 for a newsgroup in the comp.* hierarchy and if it has a valid signature
147 corresponding to the PGP key with a user ID of "news.announce.new‐
148 groups". If any newgroup claiming to be from "kre@munnari.oz.au" for a
149 newsgroup in the aus.* hierarchy is received, it too will be honored.
150 All other newgroup messages will be ignored.
151
153 The third argument for a line affecting checkgroups does not affect
154 whether the line matches. It is only used after a matching line is
155 found, to filter out which newsgroups listed in the checkgroups will be
156 processed. This means that a line like:
157 checkgroups:*:*binaries*:drop
159 will cause all checkgroups control messages to be dropped unless they
161 match a line after this one in control.ctl, not just ignore newsgroups
162 containing "binaries" in the name. The general rule is to never use
163 "*" in the second field for a line matching checkgroups messages.
164 There is unfortunately no way to do what the author of a line like the
165 above probably intended to do (yet).
166
168 Written by Rich $alz <rsalz@uunet.uu.net> for InterNetNews. Rewritten
169 in POD by Russ Allbery <rra@stanford.edu>.
170 $Id: control.ctl.5 5912 2002-12-03 05:31:11Z vinocur $
172
174 controlchan(8), inn.conf(5), innd(8), newsfeeds(5), pgpverify(8),
175 sh(1).
176INN 2.4.0 2002-12-03 CONTROL.CTL(5)