3 readers.conf - Access control and configuration for nnrpd
7 F<readers.conf> in I<pathetc> specifies access control for nnrpd(8). It
8 controls who is allowed to connect as a news reader and what they're
9 allowed to do after they connect. nnrpd reads this file when it starts
10 up. This generally means that any changes take effect immediately on all
11 subsequent connections, but B<nnrpd> may have to be restarted if you use
12 the B<-D> option. (The location I<pathetc>/readers.conf is only the
13 default; the same format applies to any file specified with C<nnrpd -c>.)
15 There are two types of entries in F<readers.conf>: parameter/value pairs
16 and configuration groups. Blank lines and anything after a number sign
17 (C<#>) are ignored, unless the character C<#> is escaped with C<\>. The
18 maximum number of characters on each line is 8,191.
20 Parameter/value pairs consist of a keyword immediately followed by a
21 colon, at least one whitespace character, and a value. The case of the
22 parameter is significant (parameter should generally be in all lowercase),
23 and a parameter may contain any characters except colon, C<#>, and
24 whitespace. An example:
28 Values that contain whitespace should be quoted with double quotes, as in:
30 hosts: "*.example.com, *.example.net"
32 If the parameter does not contain whitespace, such as:
34 hosts: *.example.com,*.example.net
36 it's not necessary to quote it, although you may wish to anyway for
39 There is no way to continue a line on the next line, and therefore no way
40 to have a single parameter with a value longer than about 8,180
43 Many parameters take a boolean value. For all such parameters, the value
44 may be specified as C<true>, C<yes>, or C<on> to turn it on and may be any
45 of C<false>, C<no>, or C<off> to turn it off. The case of these values is
48 There are two basic types of configuration groups, auth and access. The
49 auth group provides mechanisms to establish the identity of the user, who
50 they are. The access group determines, given the user's identity, what
51 that user is permitted to do. Writing a F<readers.conf> file for your
52 setup is a two-step process: first assigning an identity to each incoming
53 connection using auth groups, and then giving each identity appropriate
54 privileges with access group. We recommend I<not> intermingling auth
55 groups and access groups in the config file; it is often more sensible (in
56 the absence of the I<key> parameter) to put all of the auth groups first,
57 and all of the access groups below.
59 A user identity, as established by an auth group, looks like an e-mail
60 address; in other words, it's in the form "<username>@<domain>" (or
61 sometimes just "<username>" if no domain is specified.
63 If I<nnrpdauthsender> is set in F<inn.conf>, the user identity is also put
64 into the Sender: header of posts made by that user. See the documentation
65 of that option in inn.conf(5) for more details.
67 An auth group definition looks like:
74 default-domain: <defdomain>
75 # ...possibly other settings
78 The <name> is used as a label for the group and is only for documentation
79 purposes. (If your syslog configuration records the C<news.debug>
80 facility, the <name> will appear in the debugging output of nnrpd.
81 Examining that output can be very helpful in understanding why your
82 configuration doesn't do what you expect it to.)
84 A given auth group applies only to hosts whose name or IP address matches
85 the wildmat expression given with the hosts: parameter (comma-separated
86 wildmat expressions allowed, but C<@> is not supported). Rather than
87 wildmat expressions, you may also use CIDR notation to match any IP
88 address in a netblock; for example, "10.10.10.0/24" will match any IP
89 address between 10.10.10.0 and 10.10.10.255 inclusive.
91 If compiled against the SSL libraries, an auth group with the require_ssl:
92 parameter set to true only applies if the incoming connection is using
95 For any connection from a host that matches that wildmat expression or
96 netblock, each <res-program> (multiple res: lines may be present in a
97 block; they are run in sequence until one succeeds), if any, is run to
98 determine the identity of the user just from the connection information.
99 If all the resolvers fail, or if the res: parameter isn't present, the
100 user is assigned an identity of "<defuser>@<defdomain>"; in other words,
101 the values of the default: and default-domain: parameters are used. If
102 <res-program> only returns a username, <defdomain> is used as the
105 If the user later authenticates via the AUTHINFO USER/PASS commands, the
106 provided username and password are passed to each <auth-program> (multiple
107 auth, perl_auth, or python_auth lines may be present in a block; they are
108 run in sequence until one succeeds), if any. If one succeeds and returns
109 a different identity than the one assigned at the time of the connection,
110 it is matched against the available access groups again and the actions
111 the user is authorized to do may change. The most common <auth-program>
112 to use is B<ckpasswd>, which supports several ways of checking passwords
113 including using PAM. See the ckpasswd(8) man page for more details.
115 When matching auth groups, the last auth group in the file that matches a
116 given connection and username/password combination is used.
118 An access group definition usually looks like:
121 users: <identity-wildmat>
122 newsgroups: <group-wildmat>
123 # ...possibly other settings
126 Again, <name> is just for documentation purposes. This says that all
127 users whose identity matches <identity-wildmat> can read and post to all
128 newsgroups matching <group-wildmat> (as before, comma-separated wildmat
129 expressions are allowed, but C<@> is not supported). Alternately, you can
133 users: <identity-wildmat>
138 and matching users will be able to read any group that matches
139 <read-wildmat> and post to any group that matches <post-wildmat>. You can
140 also set several other things in the access group as well as override
141 various inn.conf(5) parameters for just a particular group of users.
143 Just like with auth groups, when matching access groups the last matching
144 one in the file is used to determine the user's permissions. There is
145 an exception to this rule: if the auth group which matched the client
146 contains a perl_access: or python_access: parameter, then the script
147 given as argument is used to dynamically generate an access group.
148 This new access group is then used to determine the access rights of
149 the client; the access groups in the file are ignored.
151 There is one additional special case to be aware of. When forming
152 particularly complex authentication and authorization rules, it is
153 sometimes useful for the identities provided by a given auth group to only
154 apply to particular access groups; in other words, rather than checking
155 the identity against the users: parameter of every access group, it's
156 checked against the users: parameter of only some specific access groups.
157 This is done with the key: parameter. For example:
171 In this case, the two key: parameters bind this auth group with this
172 access group. For any incoming connection matching "*.example.com"
173 (assuming there isn't any later auth group that also matches such hosts),
174 no access group that doesn't have "key: special" will even be considered.
175 Similarly, the above access group will only be checked if the user was
176 authenticated with an auth group containing "key: special". This
177 mechanism normally isn't useful; there is almost always a better way to
178 achieve the same result.
180 Also note in the example that there's no default-domain: parameter, which
181 means that no domain is appended to the default username and the identity
182 for such connections is just "<SPECIAL>". Note that some additional
183 add-ons to INN may prefer that authenticated identities always return a
184 full e-mail address (including a domain), so you may want to set up your
187 Below is the full list of allowable parameters for auth groups and access
188 groups, and after that are some examples that may make this somewhat
191 =head1 AUTH GROUP PARAMETERS
193 An access group without at least one of the res:, auth:, perl_auth:,
194 python_auth:, or default: parameters makes no sense (and in practice will
201 A comma-separated list of remote hosts, wildmat patterns matching either
202 hostnames or IP addresses, or IP netblocks specified in CIDR notation. If
203 a user connects from a host that doesn't match this parameter, this auth
204 group will not match the connection and is ignored.
206 Note that if you have a large number of patterns that can't be merged into
207 broader patterns (such as a large number of individual systems scattered
208 around the net that should have access), the hosts: parameter may exceed
209 the maximum line length of 8,192 characters. In that case, you'll need to
210 break that auth group into multiple auth groups, each with a portion of
211 the hosts listed in its hosts: parameter, and each assigning the same user
214 All hosts match if this parameter is not given.
216 =item B<localaddress:>
218 A comma-separated list of local host or address patterns with the same
219 syntax as the same as with the hosts: parameter. If this parameter is
220 specified, its auth group will only match connections made to a matching
221 local interface. (Obviously, this is only useful for servers with
222 multiple interfaces.)
224 All local addresses match if this parameter is not given.
228 A simple command line for a user resolver (shell metacharacters are not
229 supported). If a full path is not given, the program executed must be in
230 the I<pathbin>/auth/resolv directory. A resolver is an authentication
231 program which attempts to figure out the identity of the connecting user
232 using nothing but the connection information (in other words, the user
233 has not provided a username and password). An examples of a resolver
234 would be a program that assigns an identity from an ident callback or
235 from the user's hostname.
237 One auth group can have multiple res: parameters, and they will be tried
238 in the order they're listed. The results of the first successful one
243 A simple command line for a user authenticator (shell metacharacters are
244 not supported). If a full path is not given, the program executed must be
245 located in the I<pathbin>/auth/passwd directory. An authenticator is a
246 program used to handle a user-supplied username and password, via a
247 mechanism such as AUTHINFO USER/PASS. Like with res:, one auth group can
248 have multiple auth: parameters; they will be tried in order and the
249 results of the first successful one will be used. See also perl_auth:
252 The most common authenticator to use is ckpasswd(8); see its man page for
257 A path to a perl script for authentication. The perl_auth: parameter
258 works exactly like auth:, except that it calls the named script using
259 the perl hook rather then an external program. Multiple/mixed use of
260 the auth, perl_auth, and python_auth parameters is permitted within any
261 auth group; each line is tried in the order it appears. perl_auth:
262 has more power than auth: in that it provides the authentication
263 program with additional information about the client and the ability
264 to return an error string and a username. This parameter is only
265 valid if INN is compiled with Perl support (B<--with-perl> passed to
266 configure). More information may be found in F<doc/hook-perl>.
268 =item B<python_auth:>
270 A Python script for authentication. The I<python_auth> parameter works
271 exactly like I<auth>, except that it calls the named script (without its
272 C<.py> extension) using the Python hook rather then an external program.
273 Multiple/mixed use of the I<auth>, I<perl_auth>, and I<python_auth>
274 parameters is permitted within any auth group; each line is tried
275 in the order it appears. I<python_auth> has more power than I<auth>
276 in that it provides the authentication program with additional information
277 about the client and the ability to return an error string and a username.
278 This parameter is only valid if INN is compiled with Python support
279 (B<--with-python> passed to B<configure>). More information may be
280 found in F<doc/hook-python>.
284 The default username for connections matching this auth group. This is
285 the username assigned to the user at connection time if all resolvers fail
286 or if there are no res: parameters. Note that it can be either a bare
287 username, in which case default-domain: (if present) is appended after
288 an C<@>, or a full identity string containing an C<@>, in which case it
289 will be used verbatim.
291 =item B<default-domain:>
293 The default domain string for this auth group. If a user resolver or
294 authenticator doesn't provide a domain, or if the default username is used
295 and it doesn't contain a C<@>, this domain is used to form the user
296 identity. (Note that for a lot of setups, it's not really necessary for
297 user identities to be qualified with a domain name, in which case there's
298 no need to use this parameter.)
302 If this parameter is present, any connection matching this auth group will
303 have its privileges determined only by the subset of access groups
304 containing a matching key parameter.
306 =item B<require_ssl:>
308 If set to true, an incoming connection only matches this auth group if
309 it is encrypted using SSL. This parameter is only valid if INN is
310 compiled with SSL support (B<--with-openssl> passed to configure).
312 =item B<perl_access:>
314 A path to a perl script for dynamically generating an access group. If
315 an auth group matches successfully and contains a perl_access parameter,
316 then the argument perl script will be used to create an access group.
317 This group will then determine the access rights of the client,
318 overriding any access groups in F<readers.conf>. If and only if a
319 sucessful auth group contains the perl_access parameter, F<readers.conf>
320 access groups are ignored and the client's rights are instead determined
321 dynamically. This parameter is only valid if INN is compiled with Perl
322 support (B<--with-perl> passed to configure). More information may be
323 found in the file F<doc/hook-perl>.
325 =item B<python_access:>
327 A Python script for dynamically generating an access group. If
328 an auth group matches successfully and contains a I<python_access> parameter,
329 then the argument script (without its C<.py> extension) will be used to
330 create an access group. This group will then determine the access rights
331 of the client, overriding any access groups in F<readers.conf>. If and only
332 if a successful auth group contains the I<python_access> parameter, F<readers.conf>
333 access groups are ignored and the client's rights are instead determined
334 dynamically. This parameter is only valid if INN is compiled with Python
335 support (B<--with-python> passed to B<configure>). More information may be
336 found in the file F<doc/hook-python>.
338 =item B<python_dynamic:>
340 A Python script for applying access control dynamically on a per newsgroup
341 basis. If an auth group matches successfully and contains a
342 I<python_dynamic> parameter, then the argument script (without its
343 C<.py> extension) will be used to determine the clients rights each time
344 the user attempts to view a newsgroup, or read or post an article. Access
345 rights as determined by I<python_dynamic> override the values of access
346 group parameters such as I<newsgroups>, I<read> and I<post>. This parameter
347 is only valid if INN is compiled with Python support (B<--with-python>
348 passed to B<configure>). More information may be found in the file
353 =head1 ACCESS GROUP PARAMETERS
359 The privileges given by this access group apply to any user identity which
360 matches this comma-separated list of wildmat patterns. If this parameter
361 isn't given, the access group applies to all users (and is essentially
362 equivalent to C<users: *>).
366 Users that match this access group are allowed to read and post to all
367 newsgroups matching this comma-separated list of wildmat patterns. The
368 empty string is equivalent to C<newsgroups: *>; if this parameter is
369 missing, the connection will be rejected (unless read: and/or post: are
370 used instead, see below).
374 Like the newsgroups: parameter, but the client is only given permission to
375 read the matching newsgroups. This parameter is often used with post:
376 (below) to specify some read-only groups; it cannot be used in the same
377 access group with a newsgroups: parameter. (If read: is used and post:
378 is missing, the client will have only read-only access.)
382 Like the newsgroups: parameter, but the client is only given permission to
383 post to the matching newsgroups. This parameter is often used with read:
384 (above) to define the patterns for reading and posting separately (usually
385 to give the user permission to read more newsgroups than they're permitted
386 to post to). It cannot be used in the same access group with a
387 newsgroups: parameter.
391 A set of letters specifying the permissions granted to the client. The
392 letters are chosen from the following set:
398 The client may read articles.
402 The client may post articles.
406 The client may inject articles with IHAVE. Note that in order to
407 inject articles with the IHAVE the user must also have POST permission
412 The client may post articles with Approved: headers (in other words, may
413 approve articles for moderated newsgroups). By default, this is not
418 The client may use the NEWNEWS command, overriding the global setting.
422 The client may post to newsgroups that are set to disallow local posting
423 (mode C<n> in the active(5) file).
427 Note that if this parameter is given, I<allownewnews> in F<inn.conf> is
428 ignored for connections matching this access group and the ability of the
429 client to use NEWNEWS is entirely determined by the presence of C<N> in
430 the access string. If you want to support NEWNEWS, make sure to include
431 C<N> in the access string when you use this parameter.
433 Note that if this parameter is given and C<R> isn't present in the access
434 string, the client cannot read regardless of newsgroups: or read:
435 parameters. Similarly, if this parameter is given and C<P> isn't present,
436 the client cannot post. This use of access: is deprecated and confusing;
437 it's strongly recommended that if the access: parameter is used, C<R> and
438 C<P> always be included in the access string and newsgroups:, read:, and
439 post: be used to control access. (To grant read access but no posting
440 access, one can have just a read: parameter and no post: parameter.)
444 If this parameter is present, this access group is only considered when
445 finding privileges for users matching auth groups with this same key:
448 =item B<reject_with:>
450 If this parameter is present, a client matching this block will be
451 disconnected with a "Permission denied" message containing the contents
452 (a "reason" string) of this parameter. Some newsreaders will then
453 display the reason to the user.
457 If this parameter is present (and nonzero), it is used for B<nnrpd>'s
458 rate-limiting code. The client will only be able to download at this
459 speed (in bytes/second). Note that if SSL is being used, limiting
460 is applied to the pre-encryption datastream.
464 If a Date: header is not included in a posted article, nnrpd(8) normally
465 adds a new Date: header in UTC. If this is set to true, the Date: header
466 will be formatted in local time instead. This is a boolean value and the
471 Used as the contact address in the help message returned by nnrpd(8), if
472 the virtualhost: parameter is set to true.
476 If set to true, any Path: header provided by a user in a post is stripped
477 rather than used as the beginning of the Path: header of the article.
478 This is a boolean value and the default is false.
482 If set to false, posts made by these users do not pass through the Perl
483 filter even if it is otherwise enabled. This is a boolean value and the
486 =item B<pythonfilter:>
488 If set to false, posts made by these users do not pass through the Python
489 filter even if it is otherwise enabled. This is a boolean value and the
492 =item B<virtualhost:>
494 Set this parameter to true in order to make B<nnrpd> behave as if it is
495 running on a server with a different name than it actually is. If you
496 set this parameter to true, you must also set either pathhost: or domain:
497 in the relevant access group in F<readers.conf> to something different
498 than is set in F<inn.conf>. All articles displayed to clients will then have
499 their Path: and Xref: headers altered to appear to be from the server
500 named in pathhost: or domain: (whichever is set), and posted articles will
501 use that server name in the Path:, Message-ID:, and X-Trace: headers.
503 Note that setting this parameter requires the server modify all posts
504 before presenting them to the client and therefore may decrease
505 performance slightly.
509 In addition, all of the following parameters are valid in access groups
510 and override the global setting in F<inn.conf>. See inn.conf(5) for the
511 descriptions of these parameters:
513 addnntppostingdate, addnntppostinghost, backoff_auth, backoff_db,
514 backoff_k, backoff_postfast, backoff_postslow, backoff_trigger,
515 checkincludedtext, clienttimeout, complaints, domain,
516 fromhost, localmaxartsize, moderatormailer, nnrpdauthsender,
517 nnrpdcheckart, nnrpdoverstats, nnrpdposthost, nnrpdpostport, organization,
518 pathhost, readertrack, spoolfirst, strippostcc.
522 Here's a basic summary of what happens when a client connects:
528 All auth groups are scanned and the ones that don't match the client
529 (due to hosts:, localaddress:, require_ssl:, etc) are eliminated.
533 The remaining auth groups are scanned from the last to the first, and an
534 attempt is made to apply it to the current connection. This means running
535 res: programs, if any, and otherwise applying default:. The first auth
536 group (starting from the bottom) to return a valid user is kept as the
541 If no auth groups yield a valid user (none have default: parameters or
542 successful res: programs) but some of the auth groups have auth: lines
543 (indicating a possibility that the user can authenticate and then obtain
544 permissions), the connection is considered to have no valid auth group
545 (which means that the access groups are ignored completely) but the
546 connection isn't closed. Instead, 480 is returned for everything until
547 the user authenticates.
551 When the user authenticates, the auth groups are rescanned, and only the
552 matching ones which contain at least one auth, perl_auth, or
553 python_auth line are considered. These auth groups are scanned from
554 the last to the first, running auth: programs and perl_auth: or
555 python_auth: scripts. The first auth group (starting from the bottom)
556 to return a valid user is kept as the active auth group.
560 Regardless of how an auth group is established, as soon as one is, that
561 auth group is used to assign a user identity by taking the result of the
562 successful res, auth, perl_auth, or python_auth line (or the
563 default: if necessary), and appending the default-domain if
564 necessary. (If the perl_access: or python_access: parameter is
569 Finally, an access group is selected by scanning the access groups from
570 bottom up and finding the first match. (If the established auth group
571 contained a perl_access: or python_access line, the dynamically
572 generated access group returned by the script is used instead.)
573 User permissions are granted based on the established access group.
579 Probably the simplest useful example of a complete F<readers.conf>,
580 this gives permissions to read and post to all groups to any connections
581 from the "example.com" domain, and no privileges for anyone connecting
585 hosts: "*.example.com, example.com"
593 Note that the access realm has no users: key and therefore applies to any
594 user identity. The only available auth realm only matches hosts in the
595 "example.com" domain, though, so any connections from other hosts will be
596 rejected immediately.
598 If you have some systems that should only have read-only access to the
599 server, you can modify the example above slightly by adding an additional
600 auth and access group:
603 hosts: "*.lab.example.com"
612 If those are put in the file after the above example, they'll take
613 precedence (because they're later in the file) for any user coming from a
614 machine in the lab.example.com domain, everyone will only have read
615 access, not posting access.
617 Here's a similar example for a news server that accepts connections from
618 anywhere but requires the user to specify a username and password. The
619 username and password are first checked against an external database of
620 usernames and passwords, and then against the system shadow password file:
623 auth: "ckpasswd -d <pathdb in inn.conf>/newsusers"
632 When the user first connects, there are no res: keys and no default, so
633 they don't receive any valid identity and the connection won't match any
634 access groups (even ones with C<users: *>). Such users receive nothing
635 but authentication-required responses from nnrpd until they authenticate.
637 If they then later authenticate, the username and password are checked
638 first by running B<ckpasswd> with the B<-d> option for an external dbm
639 file of encrypted passwords, and then with the B<-s> option to check the
640 shadow password database (note that this option may require ckpasswd to
641 be setgid to a shadow group, and there are security considerations; see
642 ckpasswd(8) for details). If both of those fail, the user will continue
643 to have no identity; otherwise, an identity will be assigned (usually
644 the supplied username, perhaps with a domain appended, although an
645 authenticator technically can provide a completely different username
646 for the identity), and the access group will match, giving full access.
648 It may be educational to consider how to combine the above examples;
649 general groups always go first. The order of the auth groups actually
650 doesn't matter, since the "hosts: example.com" one only matches
651 connections before username/password is sent, and the "auth: ckpasswd"
652 one only matches after; order would matter if either group applied to
653 both cases. The order of the access groups in this case does matter,
654 provided the newsgroups: lines differ; the access group with no users:
655 line needs to be first, with the "users: <LOCAL>" group after.
657 Here's a very complicated example. This is for an organization that has
658 an internal hierarchy "example.*" only available to local shell users, who
659 are on machines where identd can be trusted. Dialup users must provide a
660 username and password, which is then checked against RADIUS. Remote users
661 have to use a username and password that's checked against a database on
662 the news server. Finally, the admin staff (users "joe" and "jane") can
663 post anywhere (including the "example.admin.*" groups that are read-only
664 for everyone else), and are exempted from the Perl filter. For an
665 additional twist, posts from dialup users have their Sender: header
666 replaced by their authenticated identity.
668 Since this organization has some internal moderated newsgroups, the admin
669 staff can also post messages with Approved: headers, but other users
673 auth: "ckpasswd -f <pathdb in inn.conf>/newsusers"
675 default-domain: example.com
679 hosts: *.shell.example.com
683 default-domain: shell.example.com
687 hosts: *.dialup.example.com
690 default-domain: dialup.example.com
694 users: *@shell.example.com
696 post: "*, !example.admin.*"
700 users: *@dialup.example.com
701 newsgroups: *,!example.*
702 nnrpdauthsender: true
706 users: "*@example.com, !<FAIL>@example.com"
707 newsgroups: *,!example.*
716 users: "joe@*,jane@*"
722 Note the use of different domains to separate dialup from shell users
723 easily. Another way to do that would be with key: parameters, but this
724 way provides slightly more intuitive identity strings. Note also that the
725 fail access group catches not only failing connections from external users
726 but also failed authentication of shell and dialup users and dialup users
727 before they've authenticated. The identity string given for, say, dialup
728 users before RADIUS authentication has been attempted matches both the
729 dialup access group and the fail access group, since it's
730 "<FAIL>@dialup.example.com", but the fail group is last so it takes
733 The shell auth group has an auth: parameter so that users joe and jane
734 can, if they choose, use username and password authentication to gain
735 their special privileges even if they're logged on as a different user on
736 the shell machines (or if ident isn't working). When they first connect,
737 they'd have the default access for that user, but they could then send
738 AUTHINFO USER and AUTHINFO PASS (or AUTHINFO SIMPLE) and get their
741 Also note that if the users joe and jane are using their own accounts,
742 they get their special privileges regardless of how they connect, whether
743 the dialups, the shell machines, or even externally with a username and
746 Finally, here's a very simple example of a configuration for a public
747 server for a particular hierarchy.
756 newsgroups: example.*
759 Notice that clients aren't allowed to read any other groups; this keeps
760 them from getting access to administrative groups or reading control
761 messages, just as a precaution. When running a public server like this,
762 be aware that many public hierarchies will later be pulled down and
763 reinjected into the main Usenet, so it's highly recommended that you also
764 run a Perl or Python filter to reject any messages crossposted out of your
765 local hierarchy and any messages containing a Supersedes: header. This
766 will keep messages posted to your public hierarchy from hurting any of the
767 rest of Usenet if they leak out.
769 =head1 SECURITY CONSIDERATIONS
771 In general, separate passwords should be used for NNTP wherever
772 possible; the NNTP protocol itself does not protect passwords from
773 casual interception, and many implementations (including this one) do
774 not "lock out" accounts or otherwise discourage password-guessing
775 attacks. So it is best to ensure that a compromised password has
778 Authentication using the AUTHINFO USER/PASS commands passes unencrypted
779 over the network. Extreme caution should therefore be used especially
780 with system passwords (e.g. C<auth: ckpasswd -s>). Passwords can be
781 protected by using NNTP over SSL or through ssh tunnels, and this usage
782 can be enforced by a well-considered server configuration that only
783 permits certain auth groups to be applied in certain cases. Here are
790 To restrict connections on the standard nntp port (119) to use SSL for
791 some (or all) of the auth groups to match, use the require_ssl:
796 If you consider your local network (but not the internet) secure, have
797 some auth groups with a restrictive hosts: parameter; they would go
798 above, with ones having global applicability below.
802 Consider running a C<nnrpd -S> (with C<-D>, or out of "super-server"
803 like B<inetd>) on the NNTPS port (563) for clients that support SSL. See
804 nnrpd(8) for more details about how to configure that. You
805 can use the require_ssl: parameter, or C<-c> to specify an alternate
806 F<readers.conf> if you want a substantially different configuration for
811 If you want to restrict an auth group to only match loopback connections
812 (for users running newsreaders on localhost or connecting via an ssh
813 tunnel), use the localaddress: parameter.
819 Written by Aidan Cully <aidan@panix.com> for InterNetNews. Substantially
820 expanded by Russ Allbery <rra@stanford.edu>.
822 $Id: readers.conf.pod 7895 2008-06-22 17:54:10Z iulius $
826 auth_krb5(8), auth_smb(8), ckpasswd(8), inn.conf(5), innd(8), newsfeeds(5),
827 nnrpd(8), uwildmat(3).