MMDF was originally developed at the University of Delaware in the late 1970s, and provided the initial means of operating CSNET, the predecessor to NSFnet. It grew in popularity throughout the 1980s, and was selected by the Santa Cruz Operation as the MTA it would distribute with SCO UNIX in 1989. It was also adopted as the basis for other commercial efforts, including the gateway used to connect the MCI Mail service to Internet mail. A re-coded variant of MMDF, called Pascal MDF (PMDF) was written at the University of Pennsylvania for VMS and was eventually commercialized through Innosoft, which subsequently ported PMDF to Tru64 Unix and Solaris. In 1999 PMDF was translated from Pascal to C. The C version of PMDF became the basis of the Sun Java System Messaging Server of Sun Microsystems, while rights to PMDF itself were purchased by Process Software, which then ported PMDF to Linux.
As its name denotes, MMDF is an MTA oriented around the idea of channels. Each means of formatting and transporting mail into or out of the mail system is a channel, and is implemented by a separate executable. This makes MMDF a highly modular system, with each module having all of the idiosyncratic syntax and semantic information necessary for a particular email technology or network, as well as the least privilege necessary, with the authority of each module partitioned from others. An inbound channel receives messages (via the protocol and in the format it implements) and an outbound channel delivers messages (via its relevant protocol and mapping into the relevant format). Internally, MMDF uses a canonical representation for message content and header, including addresses.
A message that flows through MMDF will typically follow this path:
- An inbound channel accepts a message.
- It invokes the core of the MMDF system, a program called submit, and feeds it the message as well as the out-of-band information for the message - return address, recipient, etc.
- Submit stores the message text after doing any necessary header rewriting, determines what channel(s) will be used to deliver the message, and injects the message into the queues for those channels.
- Depending on configuration, submit may then call deliver, or deliver may run later as part of periodic processing. Deliver does no direct processing of messages; instead it invokes outbound (delivery) channels, tells them which messages to process, and gives them a list of recipient addresses for each message.
- Each outbound channel delivers the message to those recipients who are to be reached by that channel, and reports to deliver which addresses were successfully delivered to.
- Deliver then updates the queues to mark the addresses that were delivered to, removes the message from any queues that have been completely processed, and if all queues have been processed removes the message text itself.
MMDF approaches administrative configuration differently than other popular MTAs. In the choice between placing specialized knowledge into the software, versus requiring that it be created through administrator's configuration instructions, MMDF chose the former. Hence, arbitrary header rewriting is performed by hard-coded software, with configuration limited to choices among existing rewriting alternatives. This makes configuration simpler and safer for administrators, who use simple key-value textual tables. It also takes more effort to create a new rewriting choice, but that effort needs to occur only one time, by a single technical expert.
The main types of tables are domain, channel, and alias tables.
- Domain tables are used for domain name canonicalization.
- Channel tables select the outbound channel on the basis of the next-hop domain name, and also encode per-domain-name parameters for the particular channel, such as the UUCP node name or IP address.
- Alias tables set up both simple aliases and mailing lists.
DNS can be and usually is used for these purposes as well, in the form of "DNS tables" that have the same key-value form. The meaning and effect of entries in these tables are more obvious than the configuration data of more generalized MTAs, but their restricted form also limits the effects that can be produced.
- Dave Crocker (August 18, 2008). "Impact of Email Work at The Rand Corporation in the mid-1970s" (PDF). Retrieved September 30, 2011.
- Ken Simpson and Stas Bekman (January 5, 2007). "Fingerprinting the World's Mail Servers". SysAdmin. O'Reilly Publishers. Retrieved September 30, 2011.