.SH
The MMDF File Hierarchy
.PP
The MMDFI queue structure consisted of three directories.
The ``msg'' directory contained the files containing actual
message text.
The ``addr'' directory contained the address list file for each
message, and the ``tmp'' directory contained the address list
while it was being created before moving it to the ``addr''
directory.
The names of the files in ``msg'' and ``addr'' were identical
although the contents differed.
This made it easy to find
the companion file given either filename.
The MMDFII queue structure has changed in one major way from that
of MMDFI.
There is now one extra directory per channel named q.\fIchannel\fR.
If an address list still has any addresses destined to be sent
on any channels,
then a link will exist from the address list
file in ``addr'' to a file with the same name in each queue directory
which is referenced.
All the above directories usually live in /usr/mmdf/lock/home,
although the
root name of this tree can be changed.
The lock directory is kept in 700 or 770 mode, accessible only to
the ``mmdf'' user and possibly a ``systems'' group for
ease of maintenance.
The ``home'' directory and all the underlying queue directories are
kept in 777 mode to allow ease of movement and access for the trusted
but unprivileged programs that operate there.
In particular, the \fBsubmit\fR process is setuid to ``mmdf''
to allow it to
enter the tree, but it then restores
its UID and GID to those of the invoker.
\fBDeliver\fR and the channel programs normally run as the ``mmdf'' user.
Only the local channel, which must access the real user's mailbox files,
and the TCP/IP network daemons, which must access privileged sockets,
need run privileged.  There are several other programs that are
setuid to ``root'', but only so they can change their UID to ``mmdf''
so as to to be a ``trusted submitter'', which allows them to specify
an arbitrary From: line.
.PP
The addition of the separate queuing directories on
a per channel basis was a valuable change.
UNIX performs poorly with large directories,
as any UUCP backbone site can tell you.
This new mechanism allows easy
partitioning of channel activities into separate directories, since
\fBdeliver\fR will never access the copy of the address list in the ``addr''
directory until it goes to finally expunge the message from the queues.
If one channel or site gets backed up, it does not affect the performance of
any of the other channels.
.PP
The format of the address lists has changed somewhat since MMDFI.
The old format was:
.in +1i
.sp .6
S T channel-name host-on-channel address-at-host
.in -1i
.sp .6
where S was either a `\-' indicating unsent or a `+' indicating that
only the address but not the text had been sent.
The T was either the type of delivery
(almost always `m' for mail) or a `*' indicating the message has been
completely delivered.  The channel-name and host-on-channel should be
obvious.  The address-at-host parameter was only the local part of an
address.
The new version differs in two ways.  First, the host-on-channel is now
the full domain address of the host to deliver to, as specified in the
routing information of the domain table.
.FN
See the manual section on the MMDF database (queue.5) for more information.
.FE
Second, the address-at-host is now the full address with
both the local-part and the domain specifier.
.PP
In the future, I will probably change the location of the ``message
completely delivered'' flag to be in the first position (S), since
I feel it was a mistake to not have it there in the past and it is
confusing in its current position.
This has not been done as of February 1985.
.PP
The MMDF file hierarchy also has a logging directory.  Separate
logs are kept here for \fBsubmit\fR and \fBdeliver\fR,
the channel programs,
and the phone dialing package.  This directory is generally
accessible although unreadable and the logs are normally write
only.  This could be made ``mmdf'' access only for some sites, with
the only penalty being that some programs would be unable to add
entries to the log.
A subdirectory of the log directory called ``log/phase'' contains
time stamp files whose modification times are changed by \fBsubmit\fR
and \fBdeliver\fR to indicate such things as last pickup time, last
delivery time, last poll made, and similar information.
.PP
There are two other directories in the MMDF hierarchy which
should be mentioned.  The ``chans'' directory contains
all of the channel programs invoked by the \fBdeliver\fR program,
and other ancillary daemon programs such as the SMTP daemon
and the SMTP server.  The ``table'' directory contains
all files necessary to maintain the MMDF database,
including domain tables, host address files, mailbox
alias files, dialing scripts, and programs to build these
files and incorporate them into the DBM library.
.FN
The DBM package is a set of simple hashed database access routines
that were distributed with V7 Unix and are still widely used.
.FE
.PP
Use of some sort of keyed database system is almost essential for large
MMDF systems, since the table lookup overhead is unbearable
otherwise.  Currently DBM is the only readily available alternative
and it does seem to work well, but it is running out of steam,
particularly due to its limited record length.  A more
flexible replacement for
this package would be welcome.
.PP
The top of the MMDF directory tree contains the directories mentioned
above, the \fBsubmit\fR and \fBdeliver\fR
programs, and a few maintenance programs.
If the site is polled for PhoneNet mail then the ``\fBslave\fR''
program is normally
also located here.  The \fBslave\fR
program is used as the remote site's login
shell and acts much as \fBuucico\fR in managing the
link level communications.
It in turn calls upon \fBsubmit\fR and \fBdeliver\fR to send and receive mail.
