dcrocker@TWG.COM (Dave Crocker) (11/11/88)
From what I have seen, this point has not been made to the general community, so it may be worth mentioning, by way of closing the barn door after the worm has turned (those of you familiar with Dave Farber will recognize his linguistic influence...) that there is another mail transport package available as an alternative to sendmail. MMDF (which used to stand for Multi-channel Memo Distribution Facility and may, still) has been in operation for 9 years and is used as the core to a number of mail networks, most notably CSNet. While I developed the original version, at the University of Delaware for Farber, the Army, and NSF (CSNet), the last 6 years has seen massive improvements made by a collection of people, originating with Doug Kingston, then of BRL, Steve Kille, still of UCL, and Dan Long, still of BBN. I am told that there is a small community of dedicated souls continuing to maintain and enhance it. Like sendmail, MMDF allows mail to be sent to processes. Unlike sendmail, this can only be done to pre-registered addresses or by the recipient. That is, the MMDF maintainer can register an alias that maps to a process or the mail recipient can have an arbitrary process invoked on the message contents. There are a number of other sercurity related features, such as filtering mail according to network pairs, host pairs, or host/net combinations. Dave
rick@SEISMO.CSS.GOV (Rick Adams) (11/12/88)
>Like sendmail, MMDF allows mail to be sent to processes. Unlike sendmail, >this can only be done to pre-registered addresses or by the recipient. This is also the way that sendmail is SUPPOSED to work. Thats why it is a bug that he was able to do it via debug mode. Try sending mail to a process on a system that doesn't have debugging compiled it. It wont work. The process has to be specified in the alias file. ---rick
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (11/12/88)
Where is MMDF available from, and what does it cost?
Mike Khaw
--
internet: mkhaw@teknowledge.arpa
uucp: {uunet|sun|ucbvax|decwrl|ames|hplabs}!mkhaw%teknowledge.arpa
hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303jordan@ADS.COM (Jordan Hayes) (11/12/88)
Like sendmail, MMDF allows mail to be sent to processes. Unlike sendmail, this can only be done to pre-registered addresses or by the recipient. before this turns into the semi-annual sendmail-bash-o-rama, i'd like to remind the general public that sendmail can be made to do this as well with changes to 3 lines of code, which jeff forys (among others) have posted elsewhere. many of us have been running this way for years. /jordan
dcrocker@TWG.COM (Dave Crocker) (11/15/88)
Perhaps my previous note was a bit too brief. Its intent was to inform the community of a mail transport system, for Unix, which was built with considerable attention to issues of management (scaling and analysis) and security. I don't know enough details about sendmail to engage in a comparison, so the comments are only about MMDF. (For that matter, I have not dealt with the MMDF code in detail since I left UDel in '82, so there may be features added that I have not heard of.) The system operates off of a single queue, with a "view" of sub-sets, using sub-directories, for different destination networks/channels. This gives very good scaling as the queue grows. Mail is added to the queue through a submission process which interacts with the user's interactive agent. The user agent runs under the user's id. The submission process runs under MMDF's separate id. Most other MMDF processes run under this un-privilged id. The local delivery channel starts as superuser, of course, but it does a setuid to the receiver as soon as it can. In particular, any receiver-controlled programs, such as one which does automatic replies when you are away from the office, run under the id of that recipient, rather than of MMDF. During submission, messages are inspected for conformance to various rules, such as having an authentic From or Sender field. This can be overridden, by "relay" accounts, in which case the mail is assumed to be coming from another machine and to have gone through authentication, already, or else the message is considered to be anonymous and a header message is attached, indicating that From/Sender are not authenticated. (On another list, there was a question about the legality of inspecting headers -- i.e., reaching inside the envelope -- and there was fear that this violated an RFC. It does not, and it is done as part of the enforcement policy that MMDF was designed to support.) Dave