PMDF-MTA is the core of a family of Internet standards-based electronic messaging products. PMDF-MTA provides the SMTP/MIME machinery for the receipt, storage, routing, and delivery of electronic messages. The PMDF product suite provides connections to many other electronic messaging environments as well as a robust framework for the development of additional, custom messaging channels.
In addition to providing message transfer services, PMDF-MTA includes POP and IMAP message store servers. When combined with Internet standards-based clients, these message store servers provide the full reach of functionality expected in a modern electronic messaging system.
Thus, PMDF-MTA can be used both as an integration engine to enable disparate mail systems to interoperate and as the Internet messaging server providing a full complement of server functions including SMTP delivery services, and POP and IMAP message store services.
PMDF-MTA includes SMTP, POP, and IMAP servers to form a complete Internet-based messaging server. The canonical message format used by PMDF-MTA’s SMTP, POP, and IMAP services is SMTP/MIME. Thus, there is no message translation required to support messaging clients that support Internet standards.
PMDF-MTA’s messaging servers are all multi-threaded. The PMDF Multi-threaded Service Dispatcher provides simple control over multiple, multi-threaded servers. The messaging servers supplied with PMDF-MTA offer levels of functionality and performance that are unparalleled.
To be truly useful in practical, real world applications, a messaging system must be extremely flexible and able to adapt to a wide range of needs, from the simple and homogenous to the most byzantine. Real world electronic messaging environments are frequently characterized by a heterogeneous collection of networks, protocols, applications, and user communities that have grown up in a rather ad hoc manner. PMDF-MTA provides the base set of messaging functions to fully implement an electronic messaging backbone between disparate mail systems. With support for Internet standard protocols, PMDF-MTA is especially suited to act as an interconnect to the Internet and Internet-based mail systems like those provided with most UNIX systems.
Users have come to expect reliable, and repliable, end-to-end electronic mail service across all networks, regardless of the number and complexity of interconnections. Electronic mail is expected to be delivered through pathways where other protocols do not work. This is the type of environment where PMDF-MTA excels. PMDF-MTA provides the facilities and flexibility needed to construct a proper messaging system from the collection of parts on hand. For example, PMDF-MTA’s extensive address processing is often used to fix up addresses produced by other, less flexible products and thereby improving interoperability.
PMDF-MTA is the core of the PMDF product set and provides the foundation upon which other layered options are added, as necessary. The PMDF-MTA component is responsible for address processing, message handling and routing, and the basic infrastructure required by all components of the PMDF product family.
In addition to the basic infrastructure, PMDF-MTA includes a set of message channels, a terminal-based user agent for mail users, servers for remote client message access using POP and IMAP protocols, and management utilities.
PMDF addressing conventions conform to the Internet domain name recommendations, standardized by RFC-2822. Translations to and from other addressing conventions are implemented within PMDF as messages are delivered to those other environments.
As messages are received by PMDF-MTA from any source, their disposition is determined based on receipt addresses. Configuration information appropriate to the messaging environment controls the address processing and, thereby, the routing and processing of messages.
In addition to determining the routing of a message, address processing can perform transformations or rewriting of addresses, as necessary. Address transformations can be applied to all addresses, both originator and recipient, allowing the implementation of canonical, centralized user addresses. Specific facilities that deal with addresses include:
The native message format implemented by PMDF-MTA conforms to the Internet Multipurpose Internet Mail Extensions (MIME) specification as defined by RFC-2045 and RFC-2049, including the MacMIME specifications defined by RFC-1740 and RFC-1741. As messages are received from any source, address handling as described above determines the next destination and enqueues the message for further processing. The enqueue operation writes message content to an on-disk queue area and, if appropriate, activates the PMDF component, or channel, that is responsible for message dequeue and delivery to the next destination.
Message enqueue may perform transformations such as character set and/or document conversion. Format conversion between several common, though non-standard, Internet conventions and MIME is also available during the message enqueue operation.
Only when a message is queued safely to non-volatile storage (i.e., disk) will any PMDF channel indicate back to the source of the message that PMDF has taken full responsibility for the message, allowing the source to remove its own copy of the message from its own message queues. Similarly, PMDF channels always await acknowledgement of the assumption of responsibility by a destination or completion of delivery before PMDF removes the message from PMDF’s message queues on non-volatile storage.
PMDF components called channels handle the actual transfer of messages into and out of the PMDF Message Transfer System. Channels contain the interfaces to the various network transports supported by PMDF as well as gateway functionality, when required.
Since PMDF’s internal format is MIME, channels to other MIME-based messaging systems do not need to alter messages. They are responsible for reliable transfer of messages. Note that the old Internet standard format for messages, RFC-822, which predates MIME, is considered a subset of MIME, and as such, is carried by the same channels and is not subject to translation.
Channels responsible for transferring messages between PMDF and any messaging environments which are not based on MIME and RFC-822 will translate messages as required. Whenever possible PMDF conforms to applicable standards when performing such translations. For example, in handling X.400 messages, PMDF conforms to RFC- 2156.
The functionality provided by PMDF channels which translate message formats is comparable to that provided by traditional gateway products. However, since PMDF channels are integrated into the product set and built atop a common foundation, they are more manageable and better able to complement one another than a multiplicity of disjoint, point-to-point solutions inherent in using traditional gateway products.
Another side benefit of the fact that all messages handled by PMDF are converted to the MIME format is that as a normal part of message routing, PMDF acts as an interface for other Message Transfer Systems that provide only limited interoperability.
PMDF has support for controlling the source of authentication information (passwords) and authentication methods used during POP and IMAP logins and SMTP message submission. This allows a site to implement a policy for how users authenticate access to messaging services based on their network location. This support is implemented using the Simple Authentication and Security Layer (SASL) technique defined in RFC-2222. PMDF’s SASL implementation allows for multiple password databases to be used for authentication as well as multiple methods for encrypting the password. Support for passwords stored in the system authorization file, the PMDF password file, and message store profiles is supplied with PMDF. Additional support for alternate pass-word sources can be added to PMDF with user-written authentication routines.
The application of authentication databases and methods can be configured to support a wide variety of environments. For instance, it is straight forward to allow authentication on a local network with plain text methods while requiring any authentication for clients that are outside of the local network to use more secure methods like CRAM-MD5 and DIGEST-MD5.
It is important to note that these techniques include support for authenticating SMTP message submission. Thus, SMTP servers can require authentication before accepting a message submission. This is a useful technique for controlling message forgeries.
Sites with critical security concerns should consider adding PMDF-TLS to the functionality provided with PMDF-MTA. PMDF-TLS provides a set of encryption services that complement the authentication control provided by PMDF-MTA’s SASL support.
PMDF-MTA includes server implementations of the POP3 and IMAP4 protocols. The PMDF POP and IMAP servers make the standard OpenVMS Mail and BSD mailboxes available to POP and IMAP clients respectively. Both POP and IMAP servers are multi-threaded implementations and can support large user communities efficiently. The PMDF IMAP server supports the IMAP4 rev1 specification and includes support for persistent UIDs necessary for disconnected operation. Support is included for hierarchical folders.
PMDF-MTA provides for the scanning of message headers using the Sieve language to accept or reject a message. Message filters can be defined per-user, per-channel, or per-system. A web form is provided that allows a user to define his/her own filters without having to know the intricacies of Sieve.
This is a language used for filtering e-mail messages at time of final delivery. Sieve is designed to be implementable on either a mail client or mail server. It is extensible, simple, and independent of access protocol, mail architecture, and operating system.
Sieve is suitable for running on a mail server where users may not be allowed to execute arbitrary programs, such as on black box IMAP servers, as it has no variables, loops, or ability to shell out to external programs.
PMDF provides a combined mail and list server, referred to as MAILSERV. MAILSERV distributes files via e-mail and allows users to subscribe or unsubscribe from mailing lists. Once PMDF’s MAILSERV has been configured, users can query the server via e-mail to determine what files and mailing lists are available.
Included with PMDF-MTA are a set of email address directory manipulation tools that can be used to move directory information between e-mail directories. For each directory, support is provided to extract directory entries from the directory, writing them to a directory-neutral file format called an LDAP Directory Interchange Format (LDIF) file, and to read directory entries from an LDIF file writing them to the directory. The following set of directories are supported:
LDIF files can be created with simple text editors. The directory coordination tools are useful when you want to make large or periodic changes to a directory. These tools are a small subset of the capabilities that are available in the PMDF-DIRSYNC product for automating the management of complex directory environments.
This facility may be configured to “loop” messages through a PMDF system or out from PMDF through an arbitrary remote system and back. A process wakes up periodically to send its loopback messages out and check on the arrival of any inbound loopback messages, and keeps track of the time such messages take to complete a loop. By monitoring whether messages are indeed succeeding in looping, and how long completion of loops is taking, PMDF managers can keep an eye on the health of the overall mail system, including remote systems.
PMDF has support for querying an LDAP server for authentication, aliases (forwarding), mailing lists, address reversal (that is, “centralized naming” or “address canonicalization”), rewrite rules (domain name rewriting), and general mapping table callouts. Standard LDAP URLs are used for the queries. You can access the LDAP directory directly from rewrite rules, alias files, and mapping tables. This means for example, you can construct a rewrite rule that pulls a last name from the left-hand side of an e-mail address, and look it up in the LDAP directory. The result from the directory can be used as the final address. This is a faster process than previous versions of PMDF in that no intermediate channel process is required.
TLS can also be used on the connection to the LDAP server if required.
PMDF offers an extensive and customizable logging function. You can make the logging function as simple or as verbose as you want. You can capture every step of a mail message from origination to delivery to receipt to response to deletion, with all the detail associated with each step. You can customize your logging activity on a per channel basis, and you can log inbound activity as well as outbound activity. Be advised that the more extensive the logging activity the slower PMDF becomes.
Additionally, PMDF offers a
log_condense utility that scans mail.log format files and produces a condensed report file with one entry for each message that has passed through PMDF. This condensed log file may be used to analyze PMDF message traffic.
PMDF-MTA includes an Application Programming Interface (API) allowing customers or third-party developers to create their own channels in order to address local integration issues. Through the API, such channels have access to all the core functionality of PMDF-MTA.
To better accommodate different developer requirements and tastes, the PMDF API includes two styles of interface: one which follows OpenVMS programming conventions and a second which follows the calling conventions familiar to C language and UNIX programmers.
The latter interface is portable to the PMDF product set on other supported platforms. The intention is to maintain the portability of the API for any of the platforms on which PMDF is available.
All PMDF modules require PMDF-MTA to be present at a geographical site. Some PMDF modules require PMDF-MTA to be installed on the same machine as the module, while other modules just require that PMDF-MTA be in the same network. The configuration of PMDF-MTA is consistent across all operating system platforms. This reduces the management effort required to maintain a mixed platform environment.
Additional PMDF-MTA licenses are required if you choose to run PMDF- MTA on more than one machine. Multiple PMDF-MTA nodes allow for redundancy, load balancing, increased availability, and higher capacity. Within an OpenVMS cluster, even a mixed-architecture cluster, multiple PMDF-MTA nodes share a single copy of the installed product and configuration data. Therefore, the management and resource overhead incurred by running multiple PMDF-MTA nodes in an OpenVMS cluster is negligible.
PMDF-MTA includes the rights to create 10 PMDF-POPSTORE and 10 PMDF- MSGSTORE accounts. This support is intended to accommodate platforms that do not have a native message store and to allow system managers to examine the capabilities of using PMDF-POPSTORE or PMDF-MSGSTORE without the need to obtain an evaluation license for these add-on products.
Two user agents are provided with PMDF-MTA: PMDF MAIL and Pine. Both PMDF MAIL and Pine are MIME-aware user agents capable of handling multipart messages and non-text body parts. Both user agents read the standard VMS Mail mailbox. PMDF MAIL is a command driven application that uses a VMS Mail compatible command set. It provides an easy transition for VMS Mail mailbox or IMAP message store servers. In addition, Pine can also be used to read Usenet News groups via NNTP.
In addition to the two user agent applications provided, PMDF-MTA supports VMS Mail, DECwindows Mail, PATH- WORKS MAIL, and any other user agent based on VMS Mail.
Note: PMDF-MTA on Unix platforms also provides Pine.
The DELIVER facility screens and processes your incoming mail automatically based on guidelines you provide. Different actions can be taken based on a message’s envelope or header addresses, subject, or content. These actions include delivering the message, filing the message away, forwarding the message, or invoking a command procedure to perform complex processing. Any actions occur immediately upon receipt of each message; you do not need to be logged in at the time a message is received in order for actions to be taken on your behalf.
|RFC Title||RFC Number|
|Simple Mail Transfer Protocol (STD 10)||821|
|Standard for the Format of Internet Text Messages (STD 11)||822|
|Mail Routing and the Domain System (STD 14)||974|
|UUCP mail interchange format standard||976|
|ISO transport services on top of the TCP||1006|
|Domain Administrator’s Guide||1032|
|Domain Administrator’s Operations Guide||1033|
|Domain names—concepts and facilities||1034|
|Domain names—implementation and specification||1035|
|DNS encoding of network names and other types||1101|
|Requirements for Internet hosts—application and support||1123|
|Mapping between full RFC-822 and RFC-822 with restricted encoding||1137|
|Interactive Mail Access Protocol—version 2||1176|
|Mapping between X.400(1988)/ISO 10021 and RFC-822||1327|
|X.400 1988 to 1984 downgrading||1328|
|Japanese Character Encoding for Internet Messages||1468|
|Equivalences between 1988 X.400 and RFC-822 Message Bodies||1494|
|Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages||1496|
|Network Services Monitoring MIB||1565|
|Mail Monitoring MIB||1566|
|SMTP Service Extension for 8bit-MIME transport||1652|
|INTERNET MESSAGE ACCESS PROTOCOL—version 4||1730|
|IMAP4 Authentication mechanism||1731|
|POP3 Authentication command||1734|
|MIME Encapsulation of Macintosh files—MacMIME||1740|
|MIME Content Type for BinHex Encoded Files||1741|
|Tags for the Identification of Languages||1766|
|MIME Encapsulation of EDI Objects||1767|
|Lighweight Directory Access Protocol||1777|
|The String Representation of Standard Attribute Syntaxes||1778|
|A String Representation of Distinguished Names||1779|
|Connection-less Lightweight X.500 Directory Access Protocol||1798|
|The Content-MD5 Header Field||1864|
|SMTP Service Extensions||1869|
|SMTP Service Extension for Message Size Declaration||1870|
|SMTP Service Extension for Delivery Status Notifications||1891|
|The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages||1892|
|Enhanced Mail System Status Codes||1893|
|An Extensible Message Format for Delivery Status Notifications||1894|
|Post Office Protocol—version 3||1939|
|An LDAP URL Format||1959|
|A String Representation of LDAP Search Filters||1960|
|SMTP Service Extension for Remote Message Queue Starting||1985|
|SMTP Service Extension for Returning Enhanced Error Codes||2034|
|Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies||2045|
|Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types||2046|
|MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text||2047|
|MIME Part Four: Registration Procedures||2048|
|Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples||2049|
|INTERNET MESSAGE ACCESS PROTOCOL—version 4rev1||2060|
|MIXER (MIME Internet X.400 Enhanced Relay): Mapping between X.400 and RFC-822/MIME||2156|
|Mapping between X.400 and RFC-822/MIME Message Bodies||2157|
|Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field||2183|
|SMTP Service Extension for Command Pipelining||2197|
|IMAP/POP Authorize Extension for Simple Challenge/Response||2195|
|Simple Authentication and Security Layer (SASL)||2222|
|UTF-8, a transformation format of ISO 10646||2279|
|An Extensible Message Format for Message Disposition Notifications||2298|
|Minimal FAX address format in Internet Mail||2304|
|Ukrainian Character Set KO18-U||2319|
|The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields||2369|
|OpenPGP Message Format||2440|
|The Batch SMTP Media Type||2442|
|POP3 Extension Mechanism||2449|
|Gateways and MIME Security Multiparts||2480|
|Using Digest Authentication as a SASL Mechanism||2831|
|Sieve: A Mail-Filtering Language||3028|
PMDF-MTA supports any valid OpenVMS or Linux configuration.
One of the following operating system environments is required: