smb (06/30/82)
References: iuvax.116
(Very long note....)
We're on CSnet, and will soon (about 2 weeks) switch over to it as our
standard mail system. Before I comment further, though, I should
explain what MMDF is.
MMDF stands for "Multi-channel Memo Distribution Facility". It was
developed by Dave Crocker at the University of Delaware as part of the
CSnet project (more on CSnet below). MMDF proper is really a
replacement for delivermail -- the program that takes a formatted
letter, and sends it out on some network. It is possible (I've done
it) to use standard Berkeley mail as your composing/reading tool but
have MMDF deliver the mail. MMDF uses the standard ARPA addressing
format -- user@host -- and will very likely track changes needed for
the new Internet addressing standard. Once MMDF gets the letter, it
verifies the addresses, expands aliases, and decides what to do with
it. Rather than use the network delimiter ('!', '@', or anything else)
the way delivermail does, it searches a host table associated with each
channel, and queues the message accordingly. The message is then
picked up by a channel module (either immediately or in the background,
depending on assorted configuration options); the channel module
attempts to deliver it.
The latest release from Delaware supplies three channels: a local
delivery channel (handled by /bin/mail in the Berkeley system), an
ARPAnet channel (more on that below), and a PhoneNet channel. This
latter is the component that most resembles uucp; it passes messages
over a tty connection. (Technically, the phone channel is two
different channels, an active module that makes calls, and a passive
one that receives them.) Doug Kingston at BRL (unc!brl-bmd!dpk) has
written a uucp channel; it takes a queued MMDF message, mungs the
header a little bit, and invokes uux to send it off someplace. (Advt.
-- my pathalias program can generate the proper host table, including
all routing information, for the uucp channel.) I've modifed the ARPA
channel (slash/hack) to talk over our local net here; my code could
easily be modified to use any local net. There will soon be an SMTP
channel (SMTP is the new ARPAnet mail transfer protocol). Etc.
What does it all mean? Well, the channel concept means that users
don't have to worry about routing and configuration. Currently, we use
the uucp channel to send letters to brl-bmd and duke, because that's
how the bulk of our traffic is going. If I were to change the channel
tables, letters would go via PhoneNet, and no one would notice.
Currently, the relay machine at Delaware polls both UNC and Duke to
pick up CSnet-bound mail; it would be trivial to change tables so that
Delaware called only one machine, which would do relaying for the
other. Again, users wouldn't notice any change.
Configuration with MMDF is a bit harder than with uucp, except for the
very simplest cases -- channels can do much more, so they need more
attention, especially at first. And the documentation is a bit
sketchy. Complex configurations can be very tricky; I've been working
with this stuff for months, and stumbled across (was hit over the head
by...) a very serious channel configuration bug just last night. And a
relay machine that polls many others will have a tough time keeping
things current; too much is compiled in. (One nice touch, though, is a
program that verifies the existence and mode of the component files,
programs, directories, etc.)
MMDF was designed from the start to be more robust and more secure than
uucp (not that that says much....). Outbound messages are stored below
a mode 700 directory, which means you can't even tell how many messages
are queued without a privileged program to help you. It's much harder
to fake messages than with uucp. It warns you after two days when it
can't deliver a message; if it finally gives up, it mails the original
back to you. Uucp often acts like a black hole.... Reliability and
availability of the CSnet relay machine has been fairly good on the
average; most of the time, it's excellent, but there have been a few
outages of several days each. Some of these have been hardware
problems; others have been caused by bugs in the MMDF software. The
most vulnerable point is that channels operate sequentially on all
messages in their queue; if there's one message that hangs or somehow
blocks things, the entire channel (and perhaps channels below it in the
priority scheme, depending on configuration) will be blocked. There's
been some talk of flagging troublesome messages, and giving up on them
after a while. (Uucp is also vulnerable to this, of course.) The
PhoneNet protocol seems somewhat less robust than uucp's packet
protocol; I've noticed more line drops than seem appropriate, though
some of that is apparently hardware flakiness. The higher-level part
is better able to handle large files. I think that its line
utilization is a bit lower than uucp's, though I'm not certain of that;
however, if you're sending a letter to several people at the same site,
it will only transmit it once -- a big advantage.
The code quality is fairly good, and very modular -- perhaps too much
so; until you get a feeling for the overall structure, it's a bit hard
to follow all the jumping around. Similar modules -- the different
channels, for example -- are structured identically; thus, if one
channel needs a session initialization entry point, *all* channels will
have one, even though it's null. The code is copiously instrumented;
with debugging turned on, one can get an excellent trace of where
things are dying. (The configuration bug I mentioned above had me
stumped till I looked at the log data. Even without debugging turned
on, one glance at it narrowed down the problem to two lines of code.
Then my only problem was to figure out why they were failing....)
CSnet is another issue entirely, though it's somewhat bound up with
MMDF. CSnet is an NSF-funded project to link together computer science
departments and industrial research labs across the country (I don't
know about Canada); the relay machine at Delaware polls the PhoneNet
sites, picks up outbound mail, and delivers inbound messages. (When
trt, swd, jte, and I planned the first implementation of netnews, we
figured we'd give away the software, and assumed that the traffic would
be light enough that individual sites could pick up their share of the
phone costs. The CSnet folks applied for a grant, and got a few VAXes,
phone money, etc., from NSF. Professors do know a few techniques that
graduate students should learn....) The link to ARPA through Delaware
is officially blessed, so we don't have to worry about political
problems at gateway machines. Because there's one main relay machine,
it's easier to keep track of delivery problems -- if a message isn't
received but has been picked up, it's got to be at Delaware. Uucp
could do this also if we had one master site relaying everything, but
Usenet is far larger (and far more anarchic) than CSnet is right now.
Conclusion (at long last): we've obviously made our choice, since we
are switching. CSnet access is definitely worthwhile, and if you want
that, you have to take MMDF. Quite apart from that, I think that its
robustness and its reconfigurability make it superior to delivermail;
given BRL's uucp channel and my version of ucbmail, you lose nothing in
flexibility or in ability to talk to all your friends on the Usenet.
(If we had sendmail, the choice would be harder; sendmail (Berkeley's
replacement for delivermail) is much more flexible than its
predecessor, and easier to customize than MMDF is.)mark (07/01/82)
Steve's description of MMDF is interesting. I'm not all that familiar
with it, but I've seen people tear out their hair trying to make it do
things that delivermail does trivially.
There are really three separate issues here. (1) CSNET as a network,
(2) Phonenet as a file transfer protocol (as opposed to uucp), and
(3) MMDF as a mail delivery system (as opposed to delivermail, or
sendmail, or even /bin/mail.) You'll notice that CSNET isn't "as opposed
to" anything, and I think they are doing a wonderful job there.
UUCP leaves a LOT to be desired as a way to get files from one place
to another. I'm not all that familiar with Phonenet, but it just about
HAS to be better. My gripes about uucp include (1) no routing, (2)
no robustness (files go into black holes), (3) security is done all
wrong (you are as restricted for sending files as for retrieving them,
and the program run on the other end runs as uucp, not you, and files
show up owned by uucp instead of you), (4) it absolutely HAS
to have an 8 bit communication path, and has to run in raw mode (thus
clobbering response on your system), (5) horrible user interface (for
example, there is no way in the world to run an "ls" or "who" on a
remote machine). Steve says Phonenet does (2) well (hopefully for
file transfer as well as mail) - I wonder how it does for the other areas?
Now, MMDF vs sendmail is a different story. In my opinion, sendmail is
1000% better than MMDF, in fact, delivermail is somewhat better than
MMDF, and sendmail is a quantum leap beyond delivermail. The major thing
MMDF mail lacks is flexibility. Aliases are nearly impossible to create:
if you want to be able to mail to "net.general" and have that fed into
the newsgroup, you have to create an entry "net.general" in /etc/passwd
(and hope the length and dot don't bother anything), make it a home
directory, create a C program which runs
system("recnews net.general");
and install that in some special file under net.general's home directory.
In comparison, in delivermail you can just put
net.general: "|recnews net.general"
in /usr/lib/aliases and run newaliases - you don't even have to be a
super user to do this, if you allow /usr/lib/aliases general write
permission. In sendmail, you don't even have to run newaliases, as this
is automatically done the next time mail goes through.
The other problem with MMDF is one delivermail shares - there are 2 or 3
"channels" (delivermail has 6, I think) that are hard coded into the
program. sendmail, on the other hand, runs completely off a configuration
table. This means that you can run the SAME BINARY of sendmail on just
about every 4.1BSD system in the world, no matter what networks it is on!
Adding a channel is done by adding a line to /usr/lib/sendmail.cf. This
file allows you to configure what nets are involved, what syntax is used
for each net, what priority to parse networks at (e.g. how to resolve
the ambiguous a!b@c), what to do to the headers as mail is passed through,
whether to send one copy of a message across a link to be remotely mailed
to several people from there, where all the appropriate gateways are,
and so on. The name of the host can be used to make host sensitive
decisions. There is an option to look up hosts for certain networks
in the aliases file, so that routing can be done. I only had to add one
line to the configuration file to support the user.host@network syntax,
and when they changed that to user@host.network, I had to add one more
line - now it understands both!
The only real problems with sendmail are that the syntax of the
configuration file is a bit cryptic if you don't deal with it every
day, and if you have some kind of network with conventions and rules
that the author did not anticipate, it will be necessary to go in and
modify the code. While it's very well written and even excessively
commented, sendmail is getting big enough to make it hard to find
the part of the code to change. Also, it could use some additional
log file capabilities (it has a logger, but it wants to write on a
special /dev/log with something listening on the other end, and it
doesn't log in much detail.)
sendmail will be on 4.2BSD and is not available before then. (I'm a
test site and am not supposed to give it to anyone else, so don't ask.)
What I think I'd like to see is phonenet talking to sendmail. Sendmail
will have no trouble with this, but phonenet might have MMDF assumptions
in it (since many people refer to that software also as MMDF), and there
is presumably some communication between the two for returning undeliverable
mail. (As anyone who posts to unix-wizards knows, MMDF loves to return
lots of verbose, annoying messages when somebody on the list's host
goes down. sendmail does not address this issue either.)
Marksteveg (07/03/82)
The CSnet people mention the following security problem (to which they openly solicit any solutions): CSnet will have name-server nodes to which one can send mail and query about identities and correct addresses of people on the net. Eventually it should be posssible to be able to send (phase III) to people by misspelled names, or description (e.g. that proff at uwisc into broad-band). The problem is that it becomes fairly trivial for some "Snidely Whiplash" character to enter descriptions in the database to make himself look like (or misspelled like) someone else whose confidential mail he wishes to steal. Naturally, one should only use "absolute" addressing for the most confidential material. But in the ultimate security sense (security people frequently go this far) one can never be sure that a particular name really goes with a person unless you physically meet them and they tell you their address. (even so can you really be sure it is not an imposter?). Slowly paralyzing paranoia creeps in..... - Steven Gutfreund
smb (07/08/82)
One correction to Mark's comments: aliases are not hard to create in MMDF; in fact, they're about as easy as in sendmail or delivermail. The only thing to watch for is that the file must be topologically sorted -- unlike delivermail, MMDF make one sequential pass through the file, and hence can't catch back-references. Mark's example (mail to 'net.general') will cause problems because '.' is a network delimiter character, and hence is interpreted to mean user 'net' on host 'general'; also, there is no way to directly expand an alias to send mail to a program instead of a file. As Mark noted, it can be done but requires a special userid.