8 date 95.12.06.22.42.25; author jromine; state Exp;
13 date 92.05.19.21.48.37; author jromine; state Exp;
18 date 92.02.06.19.25.07; author jromine; state Exp;
23 date 92.02.04.21.12.28; author jromine; state Exp;
28 date 91.01.07.16.14.24; author mh; state Exp;
33 date 90.12.18.14.33.33; author mh; state Exp;
38 date 90.04.09.20.28.27; author sources; state Exp;
43 date 90.04.09.10.06.21; author sources; state Exp;
48 date 90.04.05.15.07.43; author sources; state Exp;
53 date 90.04.02.14.28.11; author sources; state Exp;
58 date 90.03.23.15.08.48; author sources; state Exp;
63 date 90.03.22.11.30.42; author sources; state Exp;
68 date 90.03.21.10.20.06; author sources; state Exp;
73 date 90.03.20.19.59.48; author sources; state Exp;
78 date 90.03.20.14.25.28; author sources; state Exp;
83 date 90.03.16.15.55.54; author sources; state Exp;
88 date 90.02.05.14.04.11; author sources; state Exp;
93 date 89.11.17.15.56.28; author sources; state Exp;
98 date 89.06.02.11.27.07; author sources; state Exp;
113 .\" @@(#)$Id: ADMIN.rf,v 2.16 1992/05/19 21:48:37 jromine Exp jromine $
115 .de $c \" Major Heading printer
117 .b "\\s12\\n+(ch.\\ \\$1\\s0" \" 12 Point Bold Header
120 \ \ \ \\n(ch.\\ \\ \\$1
122 .sp 45p \" 45 point space or about 1/2 inch
124 \".nr xs .15v \" Put index entries closer together
129 .de $0 \" Sub-Heading macro called AFTER printing the heading
136 .de $s \" Macro to print footnote separator
137 \"\l'2i' \" No line drawn
139 . sp 1.3 \" But extra space to make up for it.
141 .fc ^ ~ \" The characters ^ and ~ CANNOT BE USED
142 \" throughout this document except as field
143 \" delimiter & pad indicator!
145 .ll 32P \" 32 Picas or about 5+1/3 inch Line Length
146 .if n .ll 72m \" Use 72 ems for nroff
147 .nr ss 30p \" 30 point space before section titles
148 .nr fm 5v \" RAND likes bigger than normal [3v] bottom margins
150 .ds . \\fB.\\fP\\h'-(1m/3)' \" Bold period to stand out.
151 .ds << <\\h!-(\\w'<'/2)!<
152 .ds >> >\\h!-(\\w'>'/2)!>
153 .ds ** \v'-3p'\s+1*\s0\v'+3p'
157 \fIdiscard this page\fR
162 Administrator's Guide
172 .uh "Scope of this document"
174 This is the Administrator's Guide to \fIMH\fR.
175 If you don't maintain an \fIMH\fR system,
177 the information is entirely too technical.
178 If you are a maintainer,
179 then read this guide until you understand it,
180 follow the advice it gives,
181 and then forget about the guide.
183 Before continuing, I'll point out two facts:
186 \fIThis document will never contain all the information
187 you need to maintain MH.
189 Furthermore, this document will never contain everything
190 I know about maintaining MH.\fR
194 and mailsystems in general,
195 are more complex than most people realize.
196 A combination of experience, intuition, and tenacity is required to maintain
198 This document can provide only guidelines for bringing up an \fIMH\fR system
200 There is a sufficient amount of customization possible that not all events or
201 problems can be forseen.
205 During \fIMH\fR generation,
206 you specify several configuration constants to the \fImhconfig\fR program.
207 These directives take into consideration such issues as hardware and
208 operating system dependencies in the source code.
209 They also factor out some major mailsystem administrative decisions
210 that are likely to be made consistantly at sites with more than one host.
211 The manual entry \fImh\-gen\fR\0(8) describes all the static configuration
215 when you install \fIMH\fR you may wish to make some site\-specific
216 or host\-specific changes which aren't hardware or even software related.
217 Rather, they are administrative decisions.
218 That's what this guide is for: it describes all of the dynamically tailorable
221 Usually, after installing \fIMH\fR, you'll want to edit the
222 \fB@@(MHETCPATH)/mtstailor\fR file.
223 This file fine-tunes the way \fIMH\fR interacts with the message transport
225 Section 2 talks about the MTS interface and MTS tailoring.
227 After that, if you're running the UCI BBoards facility,
229 you'll need to know how to maintain those systems.
230 Sections 3 and 4 talk about these.
233 you're not running an MTS that can handle both Internet and \fIUUCP\fR traffic,
234 you should read\-up on mail filtering in Section 5.
235 Although this is considered \*(lqold technology\*(rq now,
236 the mechanisms described in Section 5 were really quite useful when
237 first introduced way back in 1981.
239 Finally, you may want to know how to modify the \fIMH\fR source tree.
240 Section 6 talks (a little bit) about that.
242 The last two sections describe a few hidden features in \fIMH\fR,
243 and the configuration options that were in effect when this guide was
246 After \fIMH\fR is installed, you should define the address \*(lqBug\-MH\*(rq
247 to map to either you or the \fIPostMaster\fR at your site.
250 if you want to tailor the behavior of \fIMH\fR for new users,
251 you can create and edit the file \fB@@(MHETCPATH)/mh.profile\fR.
252 When the \fIinstall-mh\fR program is run for a user,
253 if this file exists, it will copy it into the user's \&.mh\(ruprofile
256 .\" macros for the .me/.man files
258 .he '\\$1(\\$2)'-%-'\\$1(\\$2)'
280 .b \\s-2DESCRIPTION\\s0
297 .b "\\s-2Helpful Hints\\s0"
306 .ta \w'@@(MHETCPATH)/ExtraBigFileName 'u
311 .ta \w'ExtraBigProfileName 'u
313 .b "\\s-2Profile Components\\s0"
323 .b "\\s-2See Also\\s0"
361 .+c "THE MTS INTERFACE"
363 The file \fB@@(MHETCPATH)/mtstailor\fR customizes
364 certain host\-specific parameters of \fIMH\fR
365 related primarily to interactions with the transport system.
366 The parameters in this file override the compiled\-in defaults given during
367 \fIMH\fR configuration.
368 Rather than recompiling \fIMH\fR on each host to make minor customizations,
369 it is easier simply to modify the \fBmtstailor\fR file.
370 All hosts at a given site normally use the same \fBmtstailor\fR file,
371 though this need not be the case.
373 It is a good idea to run the \fIconflict\fR\0(8) program each morning
375 The following line usually suffices:
378 00 05 * * * @@(MHETCPATH)/conflict -mail PostMaster
384 .fo '@@(MHLEFTFOOT)'@@(MHCENTERFOOT)'UCI version'
399 The UCI BBoards facility has two aspects: message reading, and
400 message delivery. The configuration directives applicable to
401 BBoards are \*(lqbboards: on/off/pop/nntp\*(rq and
402 \*(lqbbdelivery: on/off\*(rq.
403 .uh "BBoard Delivery"
405 If you enabled BBoards delivery (\*(lqbbdelivery: on\*(rq)
406 during configuration,
407 then the initial environment for bboards delivery
408 was set\-up during installation.
409 A BBoard called \*(lqsystem\*(rq is established,
410 which is the BBoard for general discussion.
412 To add more BBoards, become the \*(lqbboards\*(rq user,
413 and edit the \fB@@(BBHOME)/BBoards\fR file.
414 The file \fBsupport/bboards/Example\fR is a copy of the
415 \fB@@(BBHOME)/BBoards\fR file that we use at UCI.
416 When you add a BBoard,
417 you don't have to create the files associated with it,
418 the BBoards delivery system will do that automatically.
420 Private BBoards may be created.
421 To add the fictitious private BBoard \*(lqhacks\*(rq,
422 add the appropriate entry to the BBoards file,
423 create the empty file \fB@@(BBHOME)/hacks.mbox\fR (or whatever),
424 change the mode of this file to 0640,
425 and change the group of the file to be the groupid of the people that you
426 want to be able to read it.
427 Also be sure to add the \*(lqbboards\*(rq user to this group
428 (in \fB/etc/group\fR),
429 so the archives can be owned correctly.
431 By using the special INVIS flag for a BBoard,
432 special purpose BBoards may be set\-up which are invisible to the \fIMH\fR
435 if a site distributes a BBoard both locally to a number of machines and to a
436 number of distant machines.
437 It might be useful to have two distribution lists:
438 one for all machines on the list, and the other for local machines only.
439 This is actually very simple to do.
441 put the standard entry of information in the \fB@@(BBHOME)/BBoards\fR file,
442 with the complete distribution list.
443 For the local machines list,
444 and add a similar entry to the \fB@@(BBHOME)/BBoards\fR file.
445 All the fields should be the same except three:
446 the BBoard name should reflect a local designation (e.g., \*(lql\-hacks\*(rq),
447 the distribution list should contain only machines at the local site,
448 and the flags field should contain the INVIS flag.
449 Since the two entries share the same primary and archive files,
450 messages sent to either list are read by local users,
451 while only thoses messages sent to the main list are read by all users.
453 Two automatic facilities for dealing with BBoards exist:
454 automatic archiving and automatic aliasing.
455 The file \fBsupport/bboards/crontab\fR contains some entries that you
456 should add to your \fB/usr/lib/crontab\fR file to run the specified programs
457 at times that are convenient for you.
458 The \fBbboards.daily\fR file is run once a day and generates an alias file
460 By using this file, users of \fIMH\fR can use, for example,
461 \*(lqunix\-wizards\*(rq instead of \*(lqunix\-wizards@@brl\-vgr\*(rq
462 when they want to send a message to the \*(lqunix\-wizards\*(rq
464 This is a major win, since you just have to know the name of the group,
465 not the address where it's located.
467 The \fBbboards.weekly\fR file is run once a week and handles old
468 messages (those received more than 12 days ago) in the BBoards area.
470 those BBoards which are marked for automatic archiving
471 will have their old messages placed in the \fB@@(BBHOME)/archive/\fR area,
472 or have their old messages removed.
473 Not only does this make BBoards faster to read,
474 but it conveniently partitions the new messages from the old messages
475 so you can easily put the old messages on tape and then remove them.
476 It turns out that this automatic archiving capability is also a major
480 our policy is to save archived messages on tape (every two months or so).
481 We use a program called \fIbbtar\fR to implement our particular policy.
482 Since some BBoards are private (see above),
483 we save the archives on two tapes:
484 one containing the world\-readable archives
485 (this tape is read-only accessible to all users by calling the operator),
486 and the other containing the non\-world\-readable ones
487 (this tape is kept locked\-up somewhere).
488 .uh "BBoards with the POP"
490 If you configured \fIMH\fP with \*(lqbboards: pop\*(rq and \*(lqpop: on\*(rq,
491 then the \fIMH\fR user is allowed to read BBoards on a server machine
492 instead of the local host (thus saving disk space).
493 For completely transparent behavior,
494 the administrator may set certain variables in the \fBmtstailor\fR file
496 The variable \*(lqpopbbhost\*(rq indicates the host where BBoards are
498 (it doesn't have to be the POP service host,
499 but this host must run both a POP server and the BBoards system).
500 The variable \*(lqpopbbuser\*(rq indicates the guest account on this host
502 This username should not be either the POP user or the BBoards user.
503 Usually the anonymous FTP user (ftp) is the best choice.
504 Finally, the variable \*(lqpopbblist\*(rq indicates the name of a file which
505 contains a list of hosts (one to a line, official host names only) which
506 should be allowed to use the POP facility to access BBoards via the guest
508 (If the file is not present, then no check is made.)
510 The \*(lqpopbbuser\*(rq variable should be set on both the client and service
512 The \*(lqpopbbhost\*(rq variable need be set only on the client host
513 (the value, of course, is the name of the service host).
514 The \*(lqpopbblist\*(rq variable need be set only on the service host.
518 if a POP service host is not explicitly given by the user
519 (i.e., \*(lqpopbbhost\*(rq is implicitly used),
520 then \fIbbc\fR will explicitly check the local host prior to contacting
522 This allows each POP client host to have a few local BBoards
523 (e.g., each host could have one called \*(lqsystem\*(rq),
524 and then have the POP service host used for all the rest
525 (a site\-wide BBoard might be known as \*(lqgeneral\*(rq).
526 .uh "BBoards with the NNTP"
528 If you configured \fIMH\fP with \*(lqbboards: nntp\*(rq and \*(lqpop: on\*(rq,
530 the \fIMH\fR user is allowed to read the Network News on a
531 server machine using the standard \fIbbc\fR command.
532 For completely transparent behavior,
533 the administrator may set the \*(lqnntphost\*(rq variable in the
534 \fBmtstailor\fR file to indicate the host where the Network News is kept.
535 The \*(lqnntphost\*(rq variable should be set only on the client host
538 if an NNTP service host is not explicitly given by the user
539 (i.e., \*(lqnntphost\*(rq is implicitly used),
540 then \fIbbc\fR will explicitly check the local host prior to contacting
542 This allows each NNTP client host to have a few local BBoards
543 (e.g., each host could have one called \*(lqsystem\*(rq),
544 and then have the NNTP service host used for to read the Network News.
546 Reading BBoards via the POP and via the NNTP are mutually exclusive.
551 .fo '@@(MHLEFTFOOT)'@@(MHCENTERFOOT)'UCI version'
569 For POP (Post Office Protocol) client hosts,
570 you need to edit the \fB@@(MHETCPATH)/mtstailor\fR file to know about two
572 the SMTP service host and the POP service host.
573 Normally, these are the same.
574 Change the \*(lqlocalname\*(rq field of the \fBmtstailor\fR file
575 of \fIMH\fR in the file to be the name of the POP service host.
576 This makes replies to mail generated on the POP client host possible,
577 since \fIMH\fR will consider use the hostname of the POP service host as the
578 local hostname for outgoing mail.
579 Also set the value of \*(lqpophost\*(rq to this value.
580 This tells \fIinc\fR and \fImsgchk\fR to use POP instead of looking for mail
583 make sure the value of \*(lqservers\*(rq includes the name of the SMTP
585 The recommended value for \*(lqservers\*(rq is:
588 servers:\ SMTP\-service\-host localhost \\01localnet
590 If you want more information on the Post Office Protocol used by \fIMH\fR,
591 consult the files \fBsupport/pop/rfc1081.txt\fP and
592 \fBsupport/pop/rfc1082.txt\fP which describe the \fIMH\fP version of
595 For POP service hosts,
596 you need to run a daemon, \fIpopd\fR\0(8).
597 The daemon should start at multi\-user boot time,
602 if [ \-f /etc/popd ]; then
603 /etc/popd & echo \-n ' pop' >/dev/console
608 to the \fB/etc/rc.local\fR file is sufficient.
610 The port assigned to the POP3 protocol is \*(lq110\*(rq.
611 For historical reasons, many sites are using port \*(lq109\*(rq
612 which is the port assigned to the \*(lqPOP\*(rq (version 1 and 2) protocol.
613 The configuration option \*(lqPOPSERVICE\*(rq is the name of the
614 port number that \fIMH\fP POP will try to use, and defaults to the
617 To generate \fIMH\fP to use newer assigned port number,
618 in your \fIMH\fP config file, add:
621 options POPSERVICE='\*(lqpop3\*(rq'
623 And on both the POP client and service hosts,
624 you need to define the port that the POP service uses.
633 to the \fB/etc/services\fR file (if it's not already there).
635 There are two ways to administer POP:
636 In \*(lqnaive\*(rq mode,
637 each user-id in the \fIpasswd\fR\0(5) file is considered a POP subscriber.
638 No changes are required for the mailsystem on the POP service host.
640 this method requires that each POP subscriber have an entry in the password
642 The POP server will fetch the user's mail from wherever maildrops are kept on
643 the POP service host.
644 This means that if maildrops are kept in the user's home directory,
645 then each POP subscriber must have a home directory.
647 In \*(lqsmart\*(rq mode
648 (enabled via \*(lqDPOP\*(rq being given as a configuration option),
649 the list of POP subscribers and the list of
650 login users are completely separate name spaces.
651 A separate database (simple file similar to the \fIBBoards\fR\0(5) file)
652 is used to record information about each POP subscriber.
654 the local mailsystem must be changed to reflect this.
655 This requires two changes (both of which are simple):
657 the aliasing mechanism is augmented so that POP subscriber addresses
658 are diverted to a special delivery mechanism.
659 \fIMH\fR comes with a program, \fIpopaka\fR\0(8),
660 which generates the additional information to be put in the mailsystem's
663 a special POP channel (for MMDF-II) or POP mailer (for SendMail)
664 performs the actual delivery (\fImh.6\fR supplies both).
665 All it really does is just place the mail in the POP spool area.
667 These two different philosophies are not compatible on the same POP service
668 host: one or the other, but not both may be run.
669 Clever mailsystem people will note that
670 the POP mechanism is really a special case of the more general
673 In addition, there is one user-visible difference,
674 which the administrator controls the availability of.
675 The difference is whether the POP subscriber must supply a password to the POP
677 The first method uses the standard ARPA technique of sending a username and a
679 The appropriate programs (\fIinc\fR, \fImsgchk\fR, and possibly \fIbbc\fR\0)
680 will prompt the user for this information.
683 (which is enabled via \*(lqRPOP\*(rq being given as a configuration option)
684 uses the Berkeley UNIX reserved port method for authentication.
685 This requires that the two or three mentioned above programs be
686 \fIsetuid\fR to root.
687 (There are no known holes in any of these programs.)
689 To add a POP subscriber,
690 for the first method, one simply follows the usual procedures for adding a
691 new user, which eventually results in adding a line to the \fIpasswd\fR\0(5)
693 for the second method, one must edit the POP database file
694 (kept in the home directory of the POP user),
695 and then run the \fIpopaka\fR program.
696 The output of this program is placed in the aliases file for the transport
697 system (e.g., \fB/usr/lib/aliases\fR for SendMail).
699 Authentication for POP subscribers differs
700 depending on the two methods.
701 When the user supplies a password for the POP session:
702 under the first method,
703 the contents of the password field for the user's entry in the
704 \fIpasswd\fR\0(5) is consulted;
705 under the second method,
706 the contents of the password field for the subscriber's entry in the
707 \fIpop\fR\0(5) file is consulted.
708 (To set this field, the \fIpopwrd\fR\0(8) program is used.)
710 If you are allowing RPOP,
711 under the first method,
712 the user's \fI\&.rhosts\fR file is consulted;
713 under the second method,
714 the contents of the network address field for the subscriber's entry
715 in the \fIpop\fR\0(5) file is consulted.
718 a third authentication scheme is available.
719 When the APOP configuration option is given,
723 options APOP='\*(lq/etc/pop.auth\*(rq'
726 the server also allows a client to supply authentication
727 credentials to provide for origin authentication and reply protection,
728 but which do not involve sending a password in the clear over the network.
729 A POP authorization DB,
730 having as its name the value of APOP configuration option,
731 is used to keep track of this information.
732 This file is created and manipulated by the \fIpopauth\fR\0(8) program.
733 Because this file contains secret information,
734 it must be protected mode 0600 and owned by the super-user.
736 your first step after installing the software is to issue
741 which creates and initalizes the POP authorization DB.
746 .fo '@@(MHLEFTFOOT)'@@(MHCENTERFOOT)'UCI version'
765 There was a time when users on a UNIX host might have had two maildrops:
766 one from \fIMMDF\fR and the other from \fIUUCP\fR.
767 This was really a bad problem since it prevented using a single
768 user\-interface on all of your mail.
770 if you wanted to send a message to addresses on different mailsystems,
771 you couldn't send just one message.
772 To solve all these problems,
773 the notion of \fImail filtering\fR was developed that allowed sophisticated
774 munging and relaying between the two pseudo\-domains.
776 \fIMH\fR will perform mail filtering, transparently, if given the MF
777 configuration option.
779 with the advent of \fISendMail\fR and further maturation of \fIMMDF\fR,
780 \fIMH\fR doesn't really need to do this anymore,
781 since these message transport agents handle it.
783 The mail\-filtering stuff is too complicated.
784 It should be simpler, but, protocol translation really \fIis\fR difficult.
789 .fo '@@(MHLEFTFOOT)'@@(MHCENTERFOOT)'UCI version'
804 Finally, here's a little information on modifying the \fIMH\fR sources.
805 A word of advice however:
811 If you really want new \fIMH\fR capabilities,
812 write a shell script instead.
814 that's what UNIX is all about, isn't it?
816 Here's the organization of the \fIMH\fR source tree.
820 .ta \w'miscellany/ 'u +\w'sendmail/ 'u
821 conf/ configurator tree
822 config/ compiled configuration constants
826 miscellany/ various sundries
827 mts/ MTS\-specific areas
828 mh/ standalone delivery
829 mmdf/ MMDF\-I, MMDF\-II
830 sendmail/ SendMail, SMTP
831 papers/ papers about \fIMH\fR
833 support/ support programs and files
834 bboards/ UCI BBoards facility
837 tma/ Trusted Mail Agent (not present in all distributions)
839 zotnet/ MTS\-independent areas
840 bboards/ UCI BBoards facility
851 .fo '@@(MHLEFTFOOT)'@@(MHCENTERFOOT)'UCI version'
863 .+c "HIDDEN FEATURES"
865 The capabilities discussed here should not be used on a production basis,
866 as they are either experimental, are useful for debugging \fIMH\fR, or
867 are otherwise not recommended.
869 .uh "Debug Facilities"
871 The \fImark\fR command has a `\-debug' switch which essentially prints out
872 all the internal \fIMH\fR data structures for the folder you're looking at.
874 The \fIpost\fR command has a `\-debug' switch which does everything but
875 actually post the message for you.
876 Instead of posting the draft, it sends it to the standard output.
878 \fIsend\fR has a `\-debug' switch which gets passed to \fIpost\fR.
880 Some \fIMH\fR commands look at envariables to determine debug\-mode operation
881 of certain new facilities.
882 The current list of envariables is:
886 .ta \w'MHLPOPDEBUG 'u
887 ^MHFDEBUG~^OVERHEAD facility
890 ^MHPOPDEBUG~^POP transactions
891 ^MHVDEBUG~^window management transactions
892 ^MHWDEBUG~^alternate\-mailboxes
897 .uh "Forwarding Mail"
899 The \fIforw\fR and \fImhl\fR commands have two switches,
900 `\-dashmunging' and `\-nodashmunging' which enable or disable
901 the prepending of `\-\ ' in forwarded messages. To use
902 `\-nodashmunging', you must use an \fImhl\fR filter file.
906 The \fIsend\fR command has two switches, `\-unique' and `\-nounique',
907 which are useful to certain individuals who, for obscure reasons,
908 do not use draft\-folders.
910 \*(lqDistribution Carbon Copy\*(rq addresses may be specified in
911 the \fIDcc:\fR header.
912 This header is removed before posting the message,and a copy of the message
913 is distributed to each listed address.
914 This could be considered a form of Blind
915 Carbon Copy which is best used for sending to an address which
916 would never reply (such as an auto\-archiver).
920 If you're running a version of \fIMH\fR which talks directly to an
921 \fISMTP\fR server (or perhaps an advanced \fIMMDF\fR submit process),
922 there are lots of interesting switches for your amusement which \fIsend\fR
923 and \fIpost\fR understand:
926 .ta \w'-server host 'u
927 ^-mail~^Use the \fIMAIL\fR command (default)
928 ^-saml~^Use the \fISAML\fR command
929 ^-send~^Use the \fISEND\fR command
930 ^-soml~^Use the \fISOML\fR command
931 ^-snoop~^Watch the \fISMTP\fR transaction
932 ^-client host~^Claim to be \*(lqhost\*(rq when posting mail
933 ^-server host~^Post mail with \*(lqhost\*(rq
938 The last switch is to be useful when \fIMH\fR resides on small
939 workstations (or PC:s) in a network\-\-they can post their outgoing mail with
941 and reduce the load on the local system.
943 the `\-server\ host' switch is defaulted appropriately using the SMTP
944 search\-list mechanism.
945 The \fIwhom\fR command understands the last three switches.
950 If you are licensed to run the TTI Trusted Mail Agent (TMA),
951 here are three utility programs to manage the Key Distribution Server (KDS):
952 \fIkdsc\fR, \fIkdsd\fR, and \fIkdser\fR.
957 .fo '@@(MHLEFTFOOT)'@@(MHCENTERFOOT)'UCI version'
972 .+c "CONFIGURATION OPTIONS"
974 This manual was generated with the following configuration options in
980 .ta \w'BBoards Home Directory 'u
981 ^Generation Date~^\*(td
982 ^Primary Directory~^@@(MHBINPATH)/
983 ^Secondary Directory~^@@(MHETCPATH)/
984 ^Maildrop Location~^@@(MHDROPLOC)
986 ^BBoards Support~^Enabled
987 ^BBoards Home Directory~^@@(BBHOME)
990 ^POP Support~^Enabled
993 ^BBoards on POP~^Enabled
996 ^BBoards using NNTP~^Enabled
999 ^Trusted Mail Support~^Enabled
1005 ^Transport System~^MMDF-I \*(SM
1008 ^Transport System~^MMDF-II \*(SM
1011 ^Transport System~^SendMail \*(SM
1014 ^Transport System~^Stand\-Alone Delivery
1020 .\" table of contents
1025 .b \\s12CONTENTS\\s0
1030 .\" And now the COVER sheet
1043 ADMINISTRATOR'S GUIDE
1058 \s-2(Not to be confused with a well\-known soft drink)\s+2
1077 .\" @@(#)$Id: ADMIN.rf,v 2.15 1992/02/06 19:25:07 jromine Exp jromine $
1089 @make .Uh use smaller font
1094 .\" @@(#)$Id: ADMIN.rf,v 2.14 1992/02/04 21:12:28 jromine Exp jromine $
1103 then the server also allows a client to supply authentication
1114 .\" @@(#)$Id: ADMIN.rf,v 2.13 1991/01/07 16:14:24 mh Exp jromine $
1128 .\" @@(#)$Id: ADMIN.rf,v 2.12 90/12/18 14:33:33 mh Exp Locker: mh $
1131 which is the port assigned to the \*(lqPOP\*(rq (ver. 1) protocol.
1134 These two different philosophies are compatible on the same POP service host:
1135 to selectively disable RPOP for hosts which aren't trusted,
1136 either modify the \fI\&.rhosts\fR file in the case of POP subscribers being
1138 or zero the contents of network address field of the \fIpop\fR\0(5) file for
1139 the desired POP subscribers.
1152 .\" @@(#)$Id: ADMIN.rf,v 2.11 90/04/09 20:28:27 sources Exp Locker: mh $
1165 .\" @@(#)$Id: ADMIN.rf,v 2.10 90/04/09 10:06:21 sources Exp Locker: sources $
1168 as they are either experimental or are useful for debugging \fIMH\fR.
1171 the prepending of `\-\ ' in forwarded messages.
1183 .\" @@(#)$Id: ADMIN.rf,v 2.9 90/04/05 15:07:43 sources Exp Locker: sources $
1188 options POPSERVICE='"pop3"'
1194 pop3 110/tcp # experimental
1208 If you enable the UCI BBoards facility during configuration,
1209 then the initial environment for bboards
1213 If POP is enabled with BBoards,
1214 a third directive, POPBBoards, may be enabled.
1215 This allows the \fIMH\fR user to read BBoards on a server machine
1219 If POPBBoards is not enabled with BBoards,
1220 the directive NNTPBBoards, may be enabled.
1221 This allows the \fIMH\fR user to read the Network News on a
1224 The NNTPBBoards and POPBBoards directives are mutually exclusive.
1227 consult the file \fBsupport/pop/pop.rfc\fR,
1228 which is the \fIMH\fR revision to RFC918.
1232 on both the POP client and service hosts,
1238 pop 109/tcp # experimental
1253 @document forw/mhl -[no]dashmunging
1258 .nr fm 5v \" Rand likes bigger than normal [3v] bottom margins
1267 @put things back, do .NA stuff another way
1276 @changes for "bbhome: none"
1280 .de TH \" backward -man compatibility
1283 .de SH \" backward -man compatibility
1291 @fixup for config.sed
1305 @add .TH and .SH macros for makewhatis (getNAME.c)
1310 .fo '[mh.6]'MH'UCI version'
1313 .fo '[mh.6]'MH'UCI version'
1316 .fo '[mh.6]'MH'UCI version'
1319 .fo '[mh.6]'MH'UCI version'
1322 .fo '[mh.6]'MH'UCI version'
1325 .fo '[mh.6]'MH'UCI version'
1340 @*** empty log message ***
1349 @changes for SUN40 shared libraries and NNTP under bbc
1354 00 05 * * * /usr/uci/lib/mh/conflict -mail PostMaster
projects / mmh / blob