An analogy

One analogy for PMDF's function as an MTA (Mail Transport Agent) is that PMDF performs a similar function for e-mail messages that a central transportation transfer station performs in a city. In a city, passengers can come in to a station by way of any one of numerous possible transports--- by foot, by road, by subway, by railroad, by air, etc. Over some of these transports there can be alternate protocol possibilities: for instance, taxi cabs, busses, and private cars can all travel over roads; or another example is that commercial airlines and private airplanes provide variant forms of air travel. Depending on each passenger's destination, the passenger departs by way of an appropriate transport and protocol to get him to his next destination.

In the context of electronic mail, protocols are generally a high-level (not necessarily network specific) language spoken between two mailers, whereas transports are the low-level, network specific details used to implement a protocol on a given network.

Thus e-mail messages can come in to PMDF by any one of a variety of transports and protocols---submitted directly by a local user, via TCP/IP as an SMTP message from an Internet system, via a dial-up modem using the PhoneNet protocol, via DECnet as a MAIL-11 message, via DECnet as an SMTP message, via UUCP, via an X.400 transport, via SNA, etc. PMDF then routes the message out using a transport and protocol appropriate for the message's destination address.

Note that PMDF not only serves as a mechanism for sending and receiving mail, but also serves as a centralized switching yard or "gateway" for routing and rerouting mail traffic between multiple network transports. The use of PMDF as a mail gateway allows a PMDF host to provide electronic mail access through its network facilities for other, less capable machines.

The transportation methods---PMDF channels

PMDF uses what are called channels to implement specific combinations of transports and protocols. Each different transport and protocol combination has a corresponding different PMDF channel. The PMDF postmaster initially configures PMDF telling PMDF what sorts of transports and protocols are in use at his site, and what sorts of destination addresses should be routed through which sorts of channels. For instance, at sites with an Internet connection, Internet addresses are normally routed through an SMTP over TCP/IP channel; but at sites with only a UUCP connection, Internet addresses would instead be routed through a UUCP channel. Once PMDF is so configured, PMDF handles message routing and delivery automatically---ordinary users need never be aware of this underlying transport and routing: they simply address and send their messages and PMDF automatically routes and delivers them appropriately.

The layout of transportation routes---the PMDF configuration file

PMDF's main configuration file, the pmdf.cnf file, contains the fundamental PMDF configuration information for a site, the information about what sorts of transports and protocols are in use (PMDF channel definitions), and the information about which destination addresses should be routed through which channels (PMDF rewrite rules). This PMDF configuration file will be discussed further later in this chapter in Section 1.2, as well as in detail in Section 2.2 and Section 2.3.

The PMDF configuration file thus contains a site's "layout" in terms of transports and protocols and which destinations are reachable via what transports: akin to the physical layout of railroad tracks, bus lines, airline routes, etc., for a transportation transfer station in a city.

Arrivals trigger activity---PMDF channels run on demand

There is also the issue of scheduling: when do messages arrive and when are they delivered (when do the trains, buses, airplanes, etc., arrive and depart)?

For incoming messages, in most cases the underlying transport is simply configured to hand the messages over to PMDF immediately whenever they come in: PMDF is "passive" or "data driven", waiting for the messages, which can come in at any time.¹ For some protocol and transport combinations, the component of PMDF that awaits incoming messages for that protocol and transport combination is implemented as a server; for instance, to listen for and receive incoming SMTP over TCP/IP messages, PMDF includes an SMTP server. In other cases, for some transports where the transport itself is not able to actively hand the messages over to PMDF, PMDF is configured to periodically "poll" the sending side and ask for incoming messages.

As mentioned, PMDF is data driven. When an external source submits a message into PMDF, the receiving PMDF channel processes the message to check whither the message is destined and then typically immediately hands the message over to the appropriate outgoing channel and triggers the outgoing channel to itself run in turn. (In the case of a message with multiple recipients, the receiving channel hands the message over to multiple outgoing channels and triggers each of the outgoing channels to run.) In particular, note that for outgoing messages, by default PMDF normally always makes an immediate attempt to deliver each message.

To recapitulate, somewhat unlike the physical transportation transfer station analogy above, in PMDF the normal scheduling of outgoing message deliveries is "on-demand" and immediate---it is rather as if each new passenger could get their own railcar or airplane with immediate departure.

Delivering the passengers---the execution of PMDF channel processing jobs

The execution of the incoming direction of a PMDF channel can occur in a variety of contexts: in a user's own process (as for messages submitted by local users on the PMDF system), as a PMDF server process (as for incoming SMTP messages), or as a PMDF channel job triggered in some other way. The receiving channel immediately triggers the execution of a subsequent channel job to perform the next step of delivery of the message, and these subsequent jobs triggered by PMDF itself run in PMDF processing queues. On OpenVMS, regular OpenVMS Queue Manager queues are used for PMDF processing; thus normal OpenVMS queue handling can be used to control many details of PMDF processing. On UNIX and NT, PMDF processing queues are controlled by the PMDF Job Controller, which has its own configuration options. Configuration of exactly how and when channels run in processing queues can be used to control characteristics of PMDF operation.

Delivery retry attempts

PMDF is a store-and-forward message system. If PMDF's attempt to deliver a message encounters a temporary failure condition, then PMDF stores the message and later reattempts delivery. There are PMDF periodic jobs that run every so often re-attempting delivery of not yet delivered messages; see Section 1.4.3 later in this chapter. Eventually, if a message still cannot be delivered after repeated attempts, the PMDF periodic return job returns ("bounces") the message back to the sender. How long PMDF keeps trying to deliver messages is of course configurable---see Section 1.4.4.

The waiting room---the PMDF queue area on disk

While messages are awaiting processing and delivery by PMDF, they are stored as message files on disk in the PMDF queue area for the destination channel.

Summary

Thus there are five major aspects of PMDF operation:

1. Layout: The PMDF configuration describes how PMDF should handle messages, addresses, and message content.
2. Receiving messages: PMDF servers or incoming channel jobs receive messages. In general, PMDF is data driven. PMDF waits, listening for external agents to submit messages whenever they want.
3. Processing outbound messages: PMDF channel jobs running in PMDF processing queues deliver outbound messages. Note that a job in a PMDF processing queue can be either an immediate delivery job, or a periodic job re-attempting delivery of not-yet-delivered messages.
4. Scheduling of delivery retries and polling: For messages that do not get delivered upon first attempt, a periodic delivery job periodically reattempts delivery. Note that periodic jobs are: (a) a backup to the normal immediate delivery attempts of (3), or (b) something of an exception to the normal case of (2) wherein messages are submitted immediately by autonomous agents external to PMDF.
5. Message storage: The PMDF queue area is where message files are stored while being processed and awaiting delivery.

Additional facilities

In addition to the major issues of message routing and delivery discussed so far, sites often want to modify the addresses in e-mail messages, or convert message contents. Some simple address modifications are configured simply as part of the basic e-mail routing in the PMDF configuration file. For more complex needs, PMDF has extensive address handling facilities for address aliasing, directory lookups, mailing lists, centralized naming, etc.; see for instance Chapter 3. PMDF can also convert message contents from one character set to another, or convert message contents from various non-standard formats to MIME format; and in addition, PMDF has a facility for sites to hook in third party document convertors to perform desired attachment conversions, e.g., from Wordperfect to Microsoft Word; see in particular Chapter 6.