Jump to content

MMDF

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Davecrocker (talk | contribs) at 02:41, 11 May 2008 (→‎Design philosophy: Correct error about channels -- they are different for input than for output; and explained format mapping into canonical internal representation. /Dave). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

MMDF, the Multichannel Memorandum Distribution Facility, is a mail transfer agent (MTA), a computer program designed to transmit e-mail. It was originally developed at the University of Delaware in the late 1970s. 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. SCO now distributes both MMDF and Sendmail, with MMDF as the default MTA.

Design philosophy

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 idiosynchratic syntax and semantic information necessary for a particular email technology or network, as well as the 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.

Some examples of MMDF channels are SMTP, UUCP, and local (for deliving mail into local mailboxes and accepting mail submitted on the local system). MMDF was used on the CSNET network.

Message flow

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.

Configuration

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 for administrators, who use simple key-value textual tables.

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.

MMDF is still being developed by SCO and by others who are attached to its particular balance of security, ease of use, and generality.