admin.rf

<B>Digital的Unix操作系统VAX 4.2源码</B>

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 (ver. 1) 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
These two different philosophies are compatible on the same POP service host:
to selectively disable RPOP for hosts which aren't trusted,
either modify the \fI\&.rhosts\fR file in the case of POP subscribers being
UNIX logins,
or zero the contents of network address field of the \fIpop\fR\0(5) file for
the desired POP subscribers.
.if t \{
.ll 6.5i
.lt 6.5i
\}
.fo '@(MHLEFTFOOT)'@(MHCENTERFOOT)'UCI version'
.po -.50i
.so pop5.me
.so pop8.me
.so popaka.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 '@(MHLEFTFOOT)'@(MHCENTERFOOT)'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 '@(MHLEFTFOOT)'@(MHCENTERFOOT)'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 or are useful for debugging \fIMH\fR.

.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.

.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.
@BEGIN: TMA

.+c "TRUSTED MAIL"
.pp
If you are licensed to run the TTI Trusted Mail Agent (TMA),
here are three utility programs to manage the Key Distribution Server (KDS):
\fIkdsc\fR, \fIkdsd\fR, and \fIkdser\fR.
.if t \{
.ll 6.5i
.lt 6.5i
\}
.fo '@(MHLEFTFOOT)'@(MHCENTERFOOT)'UCI version'
.po -.50i
.so kdsc.me
.so kdsd.me
.so kdser.me
.po +.50i
.he ''-%-''
.fo ''''
.br
.if t \{
.ll 32P
.lt 32P
\}
@END: TMA

.+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~^@(MHBINPATH)/
^Secondary Directory~^@(MHETCPATH)/
^Maildrop Location~^@(MHDROPLOC)
@BEGIN: BBSERVER
^BBoards Support~^Enabled
^BBoards Home Directory~^@(BBHOME)
@END: BBSERVER
@BEGIN: POP
^POP Support~^Enabled
@END: POP
@BEGIN: BPOP
^BBoards on POP~^Enabled
@END: BPOP
@BEGIN: NNTP
^BBoards using NNTP~^Enabled
@END: NNTP
@BEGIN: TMA
^Trusted Mail Support~^Enabled
@END: TMA
@BEGIN: SMTP
.ds SM with SMTP
@END: SMTP
@BEGIN: MMDFIMTS
^Transport System~^MMDF-I \*(SM
@END: MMDFIMTS
@BEGIN: MMDFIIMTS
^Transport System~^MMDF-II \*(SM
@END: MMDFIIMTS
@BEGIN: SENDMTS
^Transport System~^SendMail \*(SM
@END: SENDMTS
@BEGIN: MHMTS
^Transport System~^Stand\-Alone Delivery
@END: MHMTS
.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