.SH
The MMDF Design
.PP
The MMDF system design has not changed fundamentally
from the original design proposed and implemented for MMDFI.
The design of MMDFI is covered in detail in the paper
``An Internetwork Memo Distribution Capability''.
.FN
D. Crocker, E. Szurkowski, and D. Farber,
``An Internetwork Memo Distribution Capability'', Datacom Conference,
September 1979.
.FE
In this chapter, I will summarize the basic design and discuss
those changes that have been made in MMDFII.
.PP
Mail software is normally classed into one of two groups.
A user agent (UA) is a program
that is responsible for providing a ``user friendly'' interface
for reading or writing mail and converting to the canonical
interface of the mail transfer agent as necessary.
A mail transfer agent (MTA) is a program or system
to which you or your user agent entrusts a message for delivery
to someone else's user agent.
There has been a great deal of confusion caused by people who
fail to realize the difference between a mail transfer agent and 
a user agent, or even that a difference exists!
There is a wide variety of user agents which can be used with
MMDF, and it is the responsibility of the use agent to provide a user interface.
This separation of the functions of user agent and mail transfer
agent has many advantages, not the least of which is that MMDF
can support many different user interfaces with ease.
Currently, there are at least five different interfaces available
including the Rand MH system, V6 style mail, Berkeley's Mail (cap-mail),
the Tenex-style Send and Msg programs, and Rmail (for UUCP).
MMDF is a mail transfer agent.
MMDF does not have, nor does it claim to have, a good ``user interface'';
instead it has a good program (MTA-UA) interface.
MMDF accepts messages for delivery either locally or to a remote
site.  It attempts to verify the validity of the addresses at submission
time to the extent possible given only a host table and a list of
local addresses.  If accepted, it will continually try to resend the
message until the retry time is exhausted at which time
the message is returned to the sender.
.PP
The MMDF system can be thought of as two subsystems, responsible
for mail submission and mail delivery, respectively.
Between these two halves is the mail queue.
The mail queue will be discussed later, but basically it stores each
message as two files, an address list with some control information, and
a separate file containing only the message text (header and body).
.PP
The submission half of the system consists mainly of one program,
called ``\fBsubmit\fR'', which is responsible for enqueuing mail to be
delivered.  As much verification as possible is performed on the
message at
submission time.
For mail destined for the local machine, this means making sure the
destination account exists, and that any local mailing list or aliases
expand properly.
For mail that has a non-local host specification, the \fBsubmit\fR
process checks to see if it knows how to reach the specified host.
Mail which for any reason is known to be undeliverable, is not accepted
for delivery.
\fBSubmit\fR is called by two types of processes.  The first group includes
user agents such as the \fBsend\fR program.  The second group 
comprises channel
programs such as \fBrmail\fR
.FN
The \fBrmail\fR program (/bin/rmail) is
invoked by uucp when delivering mail
on your system.
.FE
which are interfacing to remote mail transfer agents.
.PP
The delivery portion of MMDF is represented by two main elements: the
\fBdeliver\fR program which manages the queue, and
the channel programs which handle the details of
delivery to a specific network, host, or mail system.
The \fBdeliver\fR program takes each message which is eligible to
be delivered, and opens the appropriate address list.  For each address
in the list, \fBdeliver\fR ensures that it is running the appropriate channel
program and then passes the envelope information
.FN
The MMDF envelope information consists of the the
return address, the destination addresses, some delivery options and
a reference to the message text file.
.FE
to the channel.  A reference to the file containing the actual
message text is passed to the
channel program.  The channel decides how
to deliver the message and sees to any necessary message reformatting
that may be necessary (e.g. ``header munging'').
.PP
There is currently a variety of channels and the number is growing.
The local channel handles delivery of messages to local addresses.
The list channel is a special, somewhat incestuous, channel which acts
the role of channel, receiving user agent, and sending user agent all
in one.  The list channel resubmits mail back into the mail system
by calling \fBsubmit\fR.
This has several benefits that will be discussed later.
.FN
See the section on the list channel.
.FE
The SMTP channel delivers mail via TCP/IP connections using the SMTP
protocol.
.FN
J. Postel, ``RFC821 - Simple Mail Transfer Protocol'', Network Information
Center, SRI International, August 1982.
.FE
The phone channel uses the PhoneNet link-level protocol software
developed at the University of Delaware for sending mail over
dialup or hard-wired terminal lines.
The NIFTP channel queues mail as files to be transferred using the
NIFTP protocol used in the British research community.
The UUCP channel is used to queue requests for transfer using UUCP.
.PP
Development of MMDFII was started about the same time that the Sendmail 
mail transfer agent was being
written by Eric Allman at Berkeley.
Dave Crocker met with Eric on a number of occasions and was impressed
by his work.
Some elements of the Berkeley software were so useful that
they inspired the development of similar facilities in MMDFII.
Not the least of these was the runtime configuration file.
It is now possible to configure the MMDF software totally from a
single, ASCII-text-based configuration file.
Unlike Sendmail's terse configuration syntax, MMDF uses much more
verbose keyword/value pairing for configuration information.
MMDFII can be configured either from compiled-in values, for fast startup,
or totally from the text configuration file, or from any combination of the
two.
As a result of the fact that many values can be compiled-in, the usual
MMDF tailoring file is one-tenth the size of
a Sendmail tailoring file, and can be even smaller, even on a large relay site.
The runtime configuration file is one of the most useful additions
in MMDFII, especially for sites supporting more than one host,
since one can now run the same binaries on all machines of the same type.
Another Berkeley-inspired facility was the ability to have an alias
file entry that forces a delivery to a file or pipe.
While initially insecure, this facility has been made
reliable by adding code to /fBsubmit/fR that knows when you are
processing an alias file entry and when you are processing some
other type of address.
Simple ownership of the file containing the address was not considered
sufficient protection since there are too many
files left writable to the world that are owned by root or other
privileged users.