Applications/mh: doc/ADMIN.me comparison

comparison doc/ADMIN.me @ 0:bce86c4163a3

Initial revision

author	kono
date	Mon, 18 Apr 2005 23:46:02 +0900
parents
children

comparison

equal deleted inserted replaced

--1:000000000000
+:bce86c4163a3
+.\"	This file is automatically generated.  Do not edit!
+.\" @(#)$Id$
+.po +.75i
+.de $c                          \" Major Heading printer
+.ce
+.b "\\s12\\n+(ch.\\ \\$1\\s0"   \" 12 Point Bold Header
+.(x
+\ \ \ \\n(ch.\\ \\ \\$1
+.)x
+.sp 45p         \" 45 point space or about 1/2 inch
+..
+\".nr xs .15v     \" Put index entries closer together
+.(x
+Section
+.)x _
+.de $0          \" Sub-Heading macro called AFTER printing the heading
+.(x
+.sp .3v
+.ti .5i
+\\$1
+.)x
+..
+.de $s          \" Macro to print footnote separator
+\"\l'2i'        \" No line drawn
+.if n \
+.       sp 1.3  \" But extra space to make up for it.
+..
+.fc ^ ~         \" The characters ^ and ~ CANNOT BE USED
+\"                 throughout this document except as field
+\"                 delimiter & pad indicator!
+.he ''-%-''
+.ll 32P         \" 32 Picas or about 5+1/3 inch Line Length
+.if n .ll 72m   \" Use 72 ems for nroff
+.nr ss 30p      \" 30 point space before section titles
+.nr fm 5v       \" RAND likes bigger than normal [3v] bottom margins
+.nr bm 7v       \"   ditto
+.ds . \\fB.\\fP\\h'-(1m/3)' \" Bold period to stand out.
+.ds << <\\h!-(\\w'<'/2)!<
+.ds >> >\\h!-(\\w'>'/2)!>
+.ds ** \v'-3p'\s+1*\s0\v'+3p'
+.so version.rf
+.tp
+.(l C
+\fIdiscard this page\fR
+.sp 4
+The RAND \fIMH\fR
+Message Handling
+System:
+Administrator's Guide
+.sp
+UCI Version
+.sp 2
+\*(td
+\*(MH
+.)l
+.++ C
+.+c INTRODUCTION
+.uh "Scope of this document"
+.pp
+This is the Administrator's Guide to \fIMH\fR.
+If you don't maintain an \fIMH\fR system,
+don't read this;
+the information is entirely too technical.
+If you are a maintainer,
+then read this guide until you understand it,
+follow the advice it gives,
+and then forget about the guide.
+.pp
+Before continuing, I'll point out two facts:
+.sp 2
+.(l C
+\fIThis document will never contain all the information
+you need to maintain MH.
+.sp
+Furthermore, this document will never contain everything
+I know about maintaining MH.\fR
+.)l
+.sp 2
+\fIMH\fR,
+and mailsystems in general,
+are more complex than most people realize.
+A combination of experience, intuition, and tenacity is required to maintain
+\fIMH\fR properly.
+This document can provide only guidelines for bringing up an \fIMH\fR system
+and maintaining it.
+There is a sufficient amount of customization possible that not all events or
+problems can be forseen.
+.uh "Summary"
+.pp
+During \fIMH\fR generation,
+you specify several configuration constants to the \fImhconfig\fR program.
+These directives take into consideration such issues as hardware and
+operating system dependencies in the source code.
+They also factor out some major mailsystem administrative decisions
+that are likely to be made consistantly at sites with more than one host.
+The manual entry \fImh\-gen\fR\0(8) describes all the static configuration
+directives.
+.pp
+However,
+when you install \fIMH\fR you may wish to make some site\-specific
+or host\-specific changes which aren't hardware or even software related.
+Rather, they are administrative decisions.
+That's what this guide is for: it describes all of the dynamically tailorable
+directives.
+.pp
+Usually, after installing \fIMH\fR, you'll want to edit the
+\fB/usr/local/mh/lib/mtstailor\fR file.
+This file fine-tunes the way \fIMH\fR interacts with the message transport
+system (MTS).
+Section 2 talks about the MTS interface and MTS tailoring.
+.pp
+After that, if you're running the UCI BBoards facility,
+or the POP facility,
+you'll need to know how to maintain those systems.
+Sections 3 and 4 talk about these.
+.pp
+If for some reason
+you're not running an MTS that can handle both Internet and \fIUUCP\fR traffic,
+you should read\-up on mail filtering in Section 5.
+Although this is considered \*(lqold technology\*(rq now,
+the mechanisms described in Section 5 were really quite useful when
+first introduced way back in 1981.
+.pp
+Finally, you may want to know how to modify the \fIMH\fR source tree.
+Section 6 talks (a little bit) about that.
+.pp
+The last two sections describe a few hidden features in \fIMH\fR,
+and the configuration options that were in effect when this guide was
+generated.
+.pp
+After \fIMH\fR is installed, you should define the address \*(lqBug\-MH\*(rq
+to map to either you or the \fIPostMaster\fR at your site.
+.pp
+In addition,
+if you want to tailor the behavior of \fIMH\fR for new users,
+you can create and edit the file \fB/usr/local/mh/lib/mh.profile\fR.
+When the \fIinstall-mh\fR program is run for a user,
+if this file exists, it will copy it into the user's \&.mh\(ruprofile
+file.
+.\" macros for the .me/.man files
+.de SC
+.he '\\$1(\\$2)'-%-'\\$1(\\$2)'
+.bp
+.(x
+.ti .8i
+\\$1
+.)x
+..
+.de NA
+.b \\s-2NAME\\s0
+.ti .5i
+..
+.de SY
+.sp
+.b \\s-2SYNOPSIS\\s0
+.in 1i
+.ti .5i
+.na
+..
+.de DE
+.ad
+.sp
+.in 0
+.b  \\s-2DESCRIPTION\\s0
+.sp
+.fi
+.in .5i
+..
+.de Uh
+.ad
+.sp
+.ti .25i
+.b "\\s-2\\$1\\s0"
+.sp
+.fi
+..
+.de Hh
+.ad
+.sp
+.in 0
+.b "\\s-2Helpful Hints\\s0"
+.sp
+.fi
+.in .5i
+..
+.de Fi
+.(b L
+.ti 0
+.b \\s-2Files\\s0
+.ta \w'/usr/local/mh/lib/ExtraBigFileName  'u
+..
+.de Pr
+.)b
+.(b L F
+.ta \w'ExtraBigProfileName  'u
+.ti 0
+.b "\\s-2Profile Components\\s0"
+.ti .5i
+..
+.de Ps
+.ti .5i
+..
+.de Sa
+.)b
+.(b L F
+.ti 0
+.b "\\s-2See Also\\s0"
+.br
+..
+.de De
+.)b
+.(b L
+.in .5i
+.ti 0
+.b \\s-2Defaults\\s0
+..
+.de Ds
+..
+.de Co
+.)b
+.(b L F
+.ti 0
+.b \\s-2Context\\s0
+.br
+..
+.de Hi
+.)b
+.(b L F
+.ti 0
+.b \\s-2History\\s0
+.br
+..
+.de Bu
+.)b
+.(b L F
+.ti 0
+.b \\s-2Bugs\\s0
+.br
+..
+.de En
+.)b
+.in 0
+..
+.+c "THE MTS INTERFACE"
+.pp
+The file \fB/usr/local/mh/lib/mtstailor\fR customizes
+certain host\-specific parameters of \fIMH\fR
+related primarily to interactions with the transport system.
+The parameters in this file override the compiled\-in defaults given during
+\fIMH\fR configuration.
+Rather than recompiling \fIMH\fR on each host to make minor customizations,
+it is easier simply to modify the \fBmtstailor\fR file.
+All hosts at a given site normally use the same \fBmtstailor\fR file,
+though this need not be the case.
+.pp
+It is a good idea to run the \fIconflict\fR\0(8) program each morning
+under \fIcron\fR.
+The following line usually suffices:
+.ti +.5i
+00 05 * * * /usr/local/mh/lib/conflict -mail PostMaster
+.if t \{
+.ll 6.5i
+.lt 6.5i
+\}
+.fo '[mh.6]'MH.6.8'UCI version'
+.po -.50i
+.so mh-tailor.me
+.so mh-mts.me
+.po +.50i
+.he ''-%-''
+.fo ''''
+.br
+.if t \{
+.ll 32P
+.lt 32P
+\}
+.+c "BBOARDS"
+.pp
+The UCI BBoards facility has two aspects: message reading, and
+message delivery.  The configuration directives applicable to
+BBoards are \*(lqbboards: on/off/pop/nntp\*(rq and
+\*(lqbbdelivery: on/off\*(rq.
+.uh "BBoard Delivery"
+.pp
+If you enabled BBoards delivery (\*(lqbbdelivery: on\*(rq)
+during configuration,
+then the initial environment for bboards delivery
+was set\-up during installation.
+A BBoard called \*(lqsystem\*(rq is established,
+which is the BBoard for general discussion.
+.pp
+To add more BBoards, become the \*(lqbboards\*(rq user,
+and edit the \fB/BBoards\fR file.
+The file \fBsupport/bboards/Example\fR is a copy of the
+\fB/BBoards\fR file that we use at UCI.
+When you add a BBoard,
+you don't have to create the files associated with it,
+the BBoards delivery system will do that automatically.
+.pp
+Private BBoards may be created.
+To add the fictitious private BBoard \*(lqhacks\*(rq,
+add the appropriate entry to the BBoards file,
+create the empty file \fB/hacks.mbox\fR (or whatever),
+change the mode of this file to 0640,
+and change the group of the file to be the groupid of the people that you
+want to be able to read it.
+Also be sure to add the \*(lqbboards\*(rq user to this group
+(in \fB/etc/group\fR),
+so the archives can be owned correctly.
+.pp
+By using the special INVIS flag for a BBoard,
+special purpose BBoards may be set\-up which are invisible to the \fIMH\fR
+user.
+For example,
+if a site distributes a BBoard both locally to a number of machines and to a
+number of distant machines.
+It might be useful to have two distribution lists:
+one for all machines on the list, and the other for local machines only.
+This is actually very simple to do.
+For the main list,
+put the standard entry of information in the \fB/BBoards\fR file,
+with the complete distribution list.
+For the local machines list,
+and add a similar entry to the \fB/BBoards\fR file.
+All the fields should be the same except three:
+the BBoard name should reflect a local designation (e.g., \*(lql\-hacks\*(rq),
+the distribution list should contain only machines at the local site,
+and the flags field should contain the INVIS flag.
+Since the two entries share the same primary and archive files,
+messages sent to either list are read by local users,
+while only thoses messages sent to the main list are read by all users.
+.pp
+Two automatic facilities for dealing with BBoards exist:
+automatic archiving and automatic aliasing.
+The file \fBsupport/bboards/crontab\fR contains some entries that you
+should add to your \fB/usr/lib/crontab\fR file to run the specified programs
+at times that are convenient for you.
+The \fBbboards.daily\fR file is run once a day and generates an alias file
+for \fIMH\fR.
+By using this file, users of \fIMH\fR can use, for example,
+\*(lqunix\-wizards\*(rq instead of \*(lqunix\-wizards@brl\-vgr\*(rq
+when they want to send a message to the \*(lqunix\-wizards\*(rq
+discussion group.
+This is a major win, since you just have to know the name of the group,
+not the address where it's located.
+.pp
+The \fBbboards.weekly\fR file is run once a week and handles old
+messages (those received more than 12 days ago) in the BBoards area.
+In short,
+those BBoards which are marked for automatic archiving
+will have their old messages placed in the \fB/archive/\fR area,
+or have their old messages removed.
+Not only does this make BBoards faster to read,
+but it conveniently partitions the new messages from the old messages
+so you can easily put the old messages on tape and then remove them.
+It turns out that this automatic archiving capability is also a major
+win.
+.pp
+At UCI,
+our policy is to save archived messages on tape (every two months or so).
+We use a program called \fIbbtar\fR to implement our particular policy.
+Since some BBoards are private (see above),
+we save the archives on two tapes:
+one containing the world\-readable archives
+(this tape is read-only accessible to all users by calling the operator),
+and the other containing the non\-world\-readable ones
+(this tape is kept locked\-up somewhere).
+.uh "BBoards with the POP"
+.pp
+If you configured \fIMH\fP with \*(lqbboards: pop\*(rq and \*(lqpop: on\*(rq,
+then the \fIMH\fR user is allowed to read BBoards on a server machine
+instead of the local host (thus saving disk space).
+For completely transparent behavior,
+the administrator may set certain variables in the \fBmtstailor\fR file
+on the client host.
+The variable \*(lqpopbbhost\*(rq indicates the host where BBoards are
+kept
+(it doesn't have to be the POP service host,
+but this host must run both a POP server and the BBoards system).
+The variable \*(lqpopbbuser\*(rq indicates the guest account on this host
+for BBoards.
+This username should not be either the POP user or the BBoards user.
+Usually the anonymous FTP user (ftp) is the best choice.
+Finally, the variable \*(lqpopbblist\*(rq indicates the name of a file which
+contains a list of hosts (one to a line, official host names only) which
+should be allowed to use the POP facility to access BBoards via the guest
+account.
+(If the file is not present, then no check is made.)
+.pp
+The \*(lqpopbbuser\*(rq variable should be set on both the client and service
+host.
+The \*(lqpopbbhost\*(rq variable need be set only on the client host
+(the value, of course, is the name of the service host).
+The \*(lqpopbblist\*(rq variable need be set only on the service host.
+.pp
+Finally,
+on the client host,
+if a POP service host is not explicitly given by the user
+(i.e., \*(lqpopbbhost\*(rq is implicitly used),
+then \fIbbc\fR will explicitly check the local host prior to contacting
+the service host.
+This allows each POP client host to have a few local BBoards
+(e.g., each host could have one called \*(lqsystem\*(rq),
+and then have the POP service host used for all the rest
+(a site\-wide BBoard might be known as \*(lqgeneral\*(rq).
+.uh "BBoards with the NNTP"
+.pp
+If you configured \fIMH\fP with \*(lqbboards: nntp\*(rq and \*(lqpop: on\*(rq,
+then
+the \fIMH\fR user is allowed to read the Network News on a
+server machine using the standard \fIbbc\fR command.
+For completely transparent behavior,
+the administrator may set the \*(lqnntphost\*(rq variable in the
+\fBmtstailor\fR file to indicate the host where the Network News is kept.
+The \*(lqnntphost\*(rq variable should be set only on the client host
+Finally,
+on the client host,
+if an NNTP service host is not explicitly given by the user
+(i.e., \*(lqnntphost\*(rq is implicitly used),
+then \fIbbc\fR will explicitly check the local host prior to contacting
+the service host.
+This allows each NNTP client host to have a few local BBoards
+(e.g., each host could have one called \*(lqsystem\*(rq),
+and then have the NNTP service host used for to read the Network News.
+.pp
+Reading BBoards via the POP and via the NNTP are mutually exclusive.
+.if t \{
+.ll 6.5i
+.lt 6.5i
+\}
+.fo '[mh.6]'MH.6.8'UCI version'
+.po -.50i
+.so bboards5.me
+.so bbaka.me
+.so bbexp.me
+.so bboards8.me
+.so bbtar.me
+.po +.50i
+.he ''-%-''
+.fo ''''
+.br
+.if t \{
+.ll 32P
+.lt 32P
+\}
+.+c "POP"
+.pp
+For POP (Post Office Protocol) client hosts,
+you need to edit the \fB/usr/local/mh/lib/mtstailor\fR file to know about two
+hosts:
+the SMTP service host and the POP service host.
+Normally, these are the same.
+Change the \*(lqlocalname\*(rq field of the \fBmtstailor\fR file
+of \fIMH\fR in the file to be the name of the POP service host.
+This makes replies to mail generated on the POP client host possible,
+since \fIMH\fR will consider use the hostname of the POP service host as the
+local hostname for outgoing mail.
+Also set the value of \*(lqpophost\*(rq to this value.
+This tells \fIinc\fR and \fImsgchk\fR to use POP instead of looking for mail
+locally.
+Finally,
+make sure the value of \*(lqservers\*(rq includes the name of the SMTP
+service host.
+The recommended value for \*(lqservers\*(rq is:
+.ti +.5i
+servers:\ SMTP\-service\-host localhost \\01localnet
+.pp
+If you want more information on the Post Office Protocol used by \fIMH\fR,
+consult the files \fBsupport/pop/rfc1081.txt\fP and
+\fBsupport/pop/rfc1082.txt\fP which describe the \fIMH\fP version of
+the POP: POP3.
+.pp
+For POP service hosts,
+you need to run a daemon, \fIpopd\fR\0(8).
+The daemon should start at multi\-user boot time,
+so adding the lines:
+.sp
+.nf
+.in +.5i
+if [ \-f /etc/popd ]; then
+/etc/popd & echo \-n ' pop'			>/dev/console
+fi
+.in -.5i
+.fi
+.sp
+to the \fB/etc/rc.local\fR file is sufficient.
+.pp
+The port assigned to the POP3 protocol is \*(lq110\*(rq.
+For historical reasons, many sites are using port \*(lq109\*(rq
+which is the port assigned to the \*(lqPOP\*(rq (version 1 and 2) protocol.
+The configuration option \*(lqPOPSERVICE\*(rq is the name of the
+port number that \fIMH\fP POP will try to use, and defaults to the
+name \*(lqpop\*(rq.
+.pp
+To generate \fIMH\fP to use newer assigned port number,
+in your \fIMH\fP config file, add:
+.sp
+.ti +.5i
+options	POPSERVICE='\*(lqpop3\*(rq'
+.sp
+And on both the POP client and service hosts,
+you need to define the port that the POP service uses.
+Add the line:
+.sp
+.nf
+.in +.5i
+pop3		110/tcp
+.in -.5i
+.fi
+.sp
+to the \fB/etc/services\fR file (if it's not already there).
+.pp
+There are two ways to administer POP:
+In \*(lqnaive\*(rq mode,
+each user-id in the \fIpasswd\fR\0(5) file is considered a POP subscriber.
+No changes are required for the mailsystem on the POP service host.
+However,
+this method requires that each POP subscriber have an entry in the password
+file.
+The POP server will fetch the user's mail from wherever maildrops are kept on
+the POP service host.
+This means that if maildrops are kept in the user's home directory,
+then each POP subscriber must have a home directory.
+.pp
+In \*(lqsmart\*(rq mode
+(enabled via \*(lqDPOP\*(rq being given as a configuration option),
+the list of POP subscribers and the list of
+login users are completely separate name spaces.
+A separate database (simple file similar to the \fIBBoards\fR\0(5) file)
+is used to record information about each POP subscriber.
+Unfortunately,
+the local mailsystem must be changed to reflect this.
+This requires two changes (both of which are simple):
+First,
+the aliasing mechanism is augmented so that POP subscriber addresses
+are diverted to a special delivery mechanism.
+\fIMH\fR comes with a program, \fIpopaka\fR\0(8),
+which generates the additional information to be put in the mailsystem's
+alias file.
+Second,
+a special POP channel (for MMDF-II) or POP mailer (for SendMail)
+performs the actual delivery (\fImh.6\fR supplies both).
+All it really does is just place the mail in the POP spool area.
+.pp
+These two different philosophies are not compatible on the same POP service
+host: one or the other, but not both may be run.
+Clever mailsystem people will note that
+the POP mechanism is really a special case of the more general
+BBoards mechanism.
+.pp
+In addition, there is one user-visible difference,
+which the administrator controls the availability of.
+The difference is whether the POP subscriber must supply a password to the POP
+server:
+The first method uses the standard ARPA technique of sending a username and a
+password.
+The appropriate programs (\fIinc\fR, \fImsgchk\fR, and possibly \fIbbc\fR\0)
+will prompt the user for this information.
+.pp
+The second method
+(which is enabled via \*(lqRPOP\*(rq being given as a configuration option)
+uses the Berkeley UNIX reserved port method for authentication.
+This requires that the two or three mentioned above programs be
+\fIsetuid\fR to root.
+(There are no known holes in any of these programs.)
+.pp
+To add a POP subscriber,
+for the first method, one simply follows the usual procedures for adding a
+new user, which eventually results in adding a line to the \fIpasswd\fR\0(5)
+file;
+for the second method, one must edit the POP database file
+(kept in the home directory of the POP user),
+and then run the \fIpopaka\fR program.
+The output of this program is placed in the aliases file for the transport
+system (e.g., \fB/usr/lib/aliases\fR for SendMail).
+.pp
+Authentication for POP subscribers differs
+depending on the two methods.
+When the user supplies a password for the POP session:
+under the first method,
+the contents of the password field for the user's entry in the
+\fIpasswd\fR\0(5) is consulted;
+under the second method,
+the contents of the password field for the subscriber's entry in the
+\fIpop\fR\0(5) file is consulted.
+(To set this field, the \fIpopwrd\fR\0(8) program is used.)
+.pp
+If you are allowing RPOP,
+under the first method,
+the user's \fI\&.rhosts\fR file is consulted;
+under the second method,
+the contents of the network address field for the subscriber's entry
+in the \fIpop\fR\0(5) file is consulted.
+.pp
+In addition,
+a third authentication scheme is available.
+When the APOP configuration option is given,
+e.g.,
+.sp
+.ti +.5i
+options	APOP='\*(lq/etc/pop.auth\*(rq'
+.sp
+In this case,
+the server also allows a client to supply authentication
+credentials to provide for origin authentication and reply protection,
+but which do not involve sending a password in the clear over the network.
+A POP authorization DB,
+having as its name the value of APOP configuration option,
+is used to keep track of this information.
+This file is created and manipulated by the \fIpopauth\fR\0(8) program.
+Because this file contains secret information,
+it must be protected mode 0600 and owned by the super-user.
+Hence,
+your first step after installing the software is to issue
+.sp
+.ti +.5i
+# popauth -init
+.sp
+which creates and initalizes the POP authorization DB.
+.if t \{
+.ll 6.5i
+.lt 6.5i
+\}
+.fo '[mh.6]'MH.6.8'UCI version'
+.po -.50i
+.so pop5.me
+.so pop8.me
+.so popaka.me
+.so popauth.me
+.so popd.me
+.so popwrd.me
+.po +.50i
+.he ''-%-''
+.fo ''''
+.br
+.if t \{
+.ll 32P
+.lt 32P
+\}
+.+c "MAIL FILTERING"
+.pp
+There was a time when users on a UNIX host might have had two maildrops:
+one from \fIMMDF\fR and the other from \fIUUCP\fR.
+This was really a bad problem since it prevented using a single
+user\-interface on all of your mail.
+Furthermore,
+if you wanted to send a message to addresses on different mailsystems,
+you couldn't send just one message.
+To solve all these problems,
+the notion of \fImail filtering\fR was developed that allowed sophisticated
+munging and relaying between the two pseudo\-domains.
+.pp
+\fIMH\fR will perform mail filtering, transparently, if given the MF
+configuration option.
+However,
+with the advent of \fISendMail\fR and further maturation of \fIMMDF\fR,
+\fIMH\fR doesn't really need to do this anymore,
+since these message transport agents handle it.
+.pp
+The mail\-filtering stuff is too complicated.
+It should be simpler, but, protocol translation really \fIis\fR difficult.
+.if t \{
+.ll 6.5i
+.lt 6.5i
+\}
+.fo '[mh.6]'MH.6.8'UCI version'
+.po -.50i
+.so mf.me
+.so rmail.me
+.po +.50i
+.he ''-%-''
+.fo ''''
+.br
+.if t \{
+.ll 32P
+.lt 32P
+\}
+.+c "MH HACKING"
+.pp
+Finally, here's a little information on modifying the \fIMH\fR sources.
+A word of advice however:
+.sp 2
+.ce
+.b \s+4DON'T\s0
+.sp 2
+.lp
+If you really want new \fIMH\fR capabilities,
+write a shell script instead.
+After all,
+that's what UNIX is all about, isn't it?
+.pp
+Here's the organization of the \fIMH\fR source tree.
+.sp
+.nf
+.in +.5i
+.ta \w'miscellany/  'u +\w'sendmail/  'u
+conf/	configurator tree
+config/	compiled configuration constants
+dist/	distributor
+doc/	manual entries
+h/	include files
+miscellany/	various sundries
+mts/	MTS\-specific areas
+	mh/	standalone delivery
+	mmdf/	MMDF\-I, MMDF\-II
+	sendmail/	SendMail, SMTP
+papers/	papers about \fIMH\fR
+sbr/	subroutines
+support/	support programs and files
+	bboards/	UCI BBoards facility
+	general/	templates
+	pop/	POP facility
+tma/	Trusted Mail Agent (not present in all distributions)
+uip/	programs
+zotnet/	MTS\-independent areas
+	bboards/	UCI BBoards facility
+	mf/	Mail Filtering
+	mts/	MTS constants
+	tws/	date routines
+.re
+.in -.5i
+.fi
+.if t \{
+.ll 6.5i
+.lt 6.5i
+\}
+.fo '[mh.6]'MH.6.8'UCI version'
+.po -.50i
+.so mh-hack.me
+.po +.50i
+.he ''-%-''
+.fo ''''
+.br
+.if t \{
+.ll 32P
+.lt 32P
+\}
+.+c "HIDDEN FEATURES"
+.pp
+The capabilities discussed here should not be used on a production basis,
+as they are either experimental, are useful for debugging \fIMH\fR, or
+are otherwise not recommended.
+.uh "Debug Facilities"
+.pp
+The \fImark\fR command has a `\-debug' switch which essentially prints out
+all the internal \fIMH\fR data structures for the folder you're looking at.
+.pp
+The \fIpost\fR command has a `\-debug' switch which does everything but
+actually post the message for you.
+Instead of posting the draft, it sends it to the standard output.
+Similarly,
+\fIsend\fR has a `\-debug' switch which gets passed to \fIpost\fR.
+.pp
+Some \fIMH\fR commands look at envariables to determine debug\-mode operation
+of certain new facilities.
+The current list of envariables is:
+.sp
+.nf
+.in +.5i
+.ta \w'MHLPOPDEBUG  'u
+^MHFDEBUG~^OVERHEAD facility
+^MHLDEBUG~^mhl
+^MHPDEBUG~^pick
+^MHPOPDEBUG~^POP transactions
+^MHVDEBUG~^window management transactions
+^MHWDEBUG~^alternate\-mailboxes
+.re
+.in -.5i
+.fi
+.uh "Forwarding Mail"
+.pp
+The \fIforw\fR and \fImhl\fR commands have two switches,
+`\-dashmunging' and `\-nodashmunging' which enable or disable
+the prepending of `\-\ ' in forwarded messages.  To use
+`\-nodashmunging', you must use an \fImhl\fR filter file.
+.uh "Send"
+.pp
+The \fIsend\fR command has two switches, `\-unique' and `\-nounique',
+which are useful to certain individuals who, for obscure reasons,
+do not use draft\-folders.
+.pp
+\*(lqDistribution Carbon Copy\*(rq addresses may be specified in
+the \fIDcc:\fR header.
+This header is removed before posting the message,and a copy of the message
+is distributed to each listed address.
+This could be considered a form of Blind
+Carbon Copy which is best used for sending to an address which
+would never reply (such as an auto\-archiver).
+.uh "Posting Mail"
+.pp
+If you're running a version of \fIMH\fR which talks directly to an
+\fISMTP\fR server (or perhaps an advanced \fIMMDF\fR submit process),
+there are lots of interesting switches for your amusement which \fIsend\fR
+and \fIpost\fR understand:
+.nf
+.in +.5i
+.ta \w'-server host  'u
+^-mail~^Use the \fIMAIL\fR command (default)
+^-saml~^Use the \fISAML\fR command
+^-send~^Use the \fISEND\fR command
+^-soml~^Use the \fISOML\fR command
+^-snoop~^Watch the \fISMTP\fR transaction
+^-client host~^Claim to be \*(lqhost\*(rq when posting mail
+^-server host~^Post mail with \*(lqhost\*(rq
+.re
+.in -.5i
+.fi
+.pp
+The last switch is to be useful when \fIMH\fR resides on small
+workstations (or PC:s) in a network\-\-they can post their outgoing mail with
+a local relay,
+and reduce the load on the local system.
+On POP client hosts,
+the `\-server\ host' switch is defaulted appropriately using the SMTP
+search\-list mechanism.
+The \fIwhom\fR command understands the last three switches.
+.+c "CONFIGURATION OPTIONS"
+.pp
+This manual was generated with the following configuration options in
+effect:
+.sp 2
+.hl
+.nf
+.in +1.25i
+.ta \w'BBoards Home Directory      'u
+^Generation Date~^\*(td
+^Primary Directory~^/usr/local/mh/bin/
+^Secondary Directory~^/usr/local/mh/lib/
+^Maildrop Location~^/var/mail/$USER
+^POP Support~^Enabled
+^BBoards using NNTP~^Enabled
+^Transport System~^SendMail \*(SM
+.re
+.in -1.5i
+.fi
+.hl
+.\"	table of contents
+.he ''''
+.fo ''''
+.bp
+.ce
+.b \\s12CONTENTS\\s0
+.sp 3
+.xp y
+.xp x
+.bp
+.\"	And now the COVER sheet
+.po +.325i
+.ll 32P
+.nf
+.sp 1.5in
+.ps 24
+.vs 32
+.ft B
+.ce 4
+THE RAND MH
+MESSAGE HANDLING
+SYSTEM:
+ADMINISTRATOR'S GUIDE
+.ft R
+.sp .8i
+.ps 20
+.vs 24
+.ce
+UCI Version
+.sp 0.7i
+.ce 2
+Marshall T. Rose
+.sp 0.5i
+.ft I
+.ce 3
+First Edition:
+MH Classic
+\s-2(Not to be confused with a well\-known soft drink)\s+2
+.ft R
+.vs
+.sp 1i
+.ps 18
+.vs 22
+.ce 2
+\*(td
+\*(MH

Mercurial > hg > Applications > mh

comparison doc/ADMIN.me @ 0:bce86c4163a3