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