Article View: net.mail.headers
Article #276Re: "blaming Unix SendMail"
From: chris
Date: Sun, 22 Apr 1984 00:01
Date: Sun, 22 Apr 1984 00:01
64 lines
3822 bytes
3822 bytes
Time to toss in another couple of pennies' worth of thought here:
MMDF (the Multi-Channel Memo Distribution Facility) has in interesting
way of "dealing with" UUCP syntax. The basic idea behind MMDF is
actually quite similar to the ideas now in use in networking,
compiler design, computer design, microprocessor architecture, ...
(i.e., a lot of stuff). That is: do things modularly.
MMDF has a central input program (called submit). This is not
(repeat NOT) a good user interface; all it's good for (and it's
pretty good for it) is taking a mail message (with a sender and a
list of addressees) and putting it into a queue.
It also has a central delivery program (called deliver). This is
not an SMTP mailer, nor a UUCP mailer, nor anything else, all it's
good for is looking at queued messages and asking another program
to deliver them (or to tell it why it can't deliver them).
It then has a bunch of (mostly tiny) programs to do delivery for
various "channel"s. There is one for local mail (delivery to
user's mailboxes). There is another for CSNet PhoneNet mail [which
seems to be by far the buggiest, by the way]. I suppose that by
now there is one for X.25net mail.
And of course, there is one for UUCP mail. It takes a message and
a list of addressees, breaks up the message (one for each address
as required by some older versions of /bin/rmail), and hands it to
the "uux" program, after editing message headers to match UUCP
requirements.
On the input side, the "/bin/rmail" program is completely rewritten.
It takes in a UUCP mail message and figures out the sender's name,
and the destination address. It hands to submit a suitably edited
message for delivery to the destination.
-----------------
The interesting point about this whole system is that UUCP-style
addresses are meaningless to the MMDF system and never appear inside
it. This really has quite a bit of flexibility, because with small
changes to the UUCP-in and UUCP-out programs, you can change the
way the UUCP-world sees you. You never have to touch the queueing
system. It also means that one can get rid of UUCP syntax in small,
relatively painless bits at a time.
-----------------
This is not to say that MMDF is the best system there is. There
were a few bugs in the original distribution, some serious, some
minor, and the code is incredibly inefficient in some respects.
To mail to a mere hundred people takes it many CPU-minutes, inspecting
your five hundred line alias file a hundred times. A hundred and
fifty messages in the queue, and it takes ten minutes for deliver
to even start delivering. And to look up a host name alone in the
four or five alias tables can take seconds. If you put this together
on a Vax 11/780 whose afternoon load average is over 35, you can
have lots of fun trying to send mail.
But on the other hand, there's a new version that uses better
database schemes, multiple queues, etc., which gets around most of
that. (And I've done some work myself; things are much better now
here.)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris.umcp-cs@CSNet-Relay
Technical Details
Message-ID:
<6689@umcp-cs.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!watmath!clyde!akgua!mcnc!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!chrisReferences:
<491@hou3c.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!akgua!mcnc!decvax!harpo!seismo!rlgvax!cvl!umcp-cs!chris From: chris@umcp-cs.UUCP Newsgroups: net.mail.headers Subject: Re: "blaming Unix SendMail" Message-ID: <6689@umcp-cs.UUCP> Date: Sat, 21-Apr-84 19:01:25 EST Article-I.D.: umcp-cs.6689 Posted: Sat Apr 21 19:01:25 1984 Date-Received: Mon, 23-Apr-84 01:26:27 EST References: <491@hou3c.UUCP> Organization: Univ. of Maryland, Computer Science Dept. Lines: 64