Message routing in MMDF

System Overview

The MMDF system can be thought of as two subsystems, responsible for mail submission and mail delivery, respectively. Between these two halves is the mail queue. The mail queue will be discussed later, but basically it stores each message as two files, an address list with some control information, and a separate file containing only the message text (header and body).

The submission half of the system consists mainly of one program, called submit, which is responsible for enqueuing mail to be delivered. As much verification as possible is performed on the message at submission time. For mail destined for the local machine, this means making sure the destination account exists, and that any local mailing list or aliases expand properly. For mail that has a non-local host specification, the submit process checks to see if it knows how to reach the specified host. Mail which for any reason is known to be undeliverable, is not accepted for delivery.

The delivery portion of MMDF is represented by two main elements: the deliver program which manages the queue, and the channel programs which handle the details of delivery to a specific network, host, or mail system. The deliver program takes each message which is eligible to be delivered, and opens the appropriate address list. For each address in the list, deliver ensures that it is running the appropriate channel program and then passes the envelope information to the channel. A reference to the file containing the actual message text is passed to the channel program. The channel decides how to deliver the message and sees to any necessary message reformatting that may be necessary (e.g. ``header munging'').

Here is a stolen diagram: 

                    -----------      -----------
                    |  User   |      |Protocol |
                    |Interface|      | Server  |
                    -----------      -----------
                         |         /
 ___________________     |       /
 |                  \\\\    |     /
 |                  -----------
 |                  | Submit  |
 |                  |         |
 |                  -----------  . . . . . . . .->
 |                       .                         Message
 |                       .
 |                       .                         Queues
 |                  ----------- <- . . . . . . . .
 |                  | Deliver |
 |                  |         |
 |                  -----------
 |                /      |     \\\\
 |              /        |       \\\\
 |            /          |         \\\\
 | -----------      -----------      -----------
 | |  List   |      |  Local  |      |Protocol |
 | | Channel |      | Channel |      | Channel |
 | -----------      -----------      -----------
 |______|

Address handling

Understanding how message routing works is crucial to understanding the whole operation of MMDF. The routing process is performed, independently, for each address that MMDF has to deal with. There are two distinct phases in MMDF routing for a single address:
Address parsing and formalisation.
This step uses the domain tables. The address being checked, which may be incomplete, partial, use non-formal syntax (such as !, %, and so on) is looked up (in order) in the domain tables. The address may be completed or sanitised. The address may even get rewritten (as would happen if DNS is being used and mail to a CNAME is attempted). The domain tables may also add an indirect routing for the domain.

So, for example:

Delivery channel identification.
Once the address is looked up and checked to MMDF's satisfaction, it will have an initial destination host (or domain); this will be the first in the chain in the case of a multi-hop route. This host/domain will be looked up in the channel tables. Again, the channel tables are searched in the order that they appear in the tailor file. The first hit will determine the channel that will be used to deliver the message.

Complete, and fairly gory, details on this process appear in Addressing in MMDF-II.

Up to toplevel, on to domain tables.