PMDF-MTA Software Product Description


PMDF-MTA Software Product Description (PDF)

Download a PDF version of this document


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.


The Core Features of PMDF-MTA

  • Provides alias lookups on all channels
  • Offers simplified anti-relaying setup
  • Provides for the scanning of message headers using the Sieve language to accept or reject a message
  • Incorporates the latest Internet standards for electronic messaging
  • Includes the following Internet messaging servers: SMTP, POP, and IMAP
  • Provides the SMTP/MIME machinery for the receipt, storage, routing, and delivery of electronic messages
  • Provides the following facilities for address handling:
    • Addressing Channel
    • Aliasing
    • Directory Channel
    • Domain Rewriting Rules
    • Forward Mapping
    • Reverse Database and Reverse Mapping
  • Conforms to the latest MIME specifications
  • Includes the following channels:
    • Addressing
    • Alphanumeric Pager
    • Conversion
    • DECnet
    • Directory
    • Disclaimer
    • Local
    • MessageStore
    • Pipe
    • popstore
    • Printer
    • SMTP
    • TCP/IP
  • Supports authentication control using the Simple Authentication and Security Layer (SASL) technique defined in RFC-2222
  • Automatic password transitioning
  • Includes server implementation of the POP3 and IMAP4 server protocols
  • Provides MAILSERV, a combined mail and list server used to distribute files via email and allow users to subscribe or unsubscribe from mailing lists
  • Includes an Application Programming Interface (API) allowing customers or third-party developers to create their own channels to address local integration issues
  • Supports VMS clusters


Internet Messaging Servers

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.


Message Integration

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.


Addressing Conventions

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:

  • Addressing Channel - provides the facility to extract addressing information from the message body of a message. This can be useful when interoperating with mail systems that have a limited address space, for example, a system like PROFS that requires all recipients to be registered.
  • Aliasing - provides a mapping of an address or list of addresses to an arbitrarily large number of mailboxes.
  • Directory Channel - provides a mapping of mailbox names in pseudo domains into mailboxes on real systems. The mapping of pseudo domains can be based on: PMDF databases, LDAP directory look ups, or CCSO/qi/ph look ups.
  • Domain Rewriting Rules - provides the primary facility within PMDF for routing and manipulating the host/domain portion of addresses.
  • Forward Mapping - provides the facility for address transformations based on a generalized pattern matching schema for the Header To: addresses and other forward-pointing addresses.
  • Reverse Database - provides the facility for address transformations based on a table lookup for the Header From: addresses and other backward-pointing envelope fields. This can be used for forward-pointing addresses as well. This processing can be extended to all header addresses.
  • Reverse Mapping - provides the facility for address transformations based on generalized pattern matching schema for the Header From: addresses and other backward-pointing envelope fields. This can be used for forward-pointing addresses as well. This processing can be extended to all header addresses.


Message Handling

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.


Message Transfer and Translation

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.



  • Addressing - for the extraction of addressing information from the body of a message and message delivery based on that extracted address.
  • Alphanumeric Pager - for dial-up delivery to TAP, IXO, or PET paging switches.
  • Conversion - for conversion of message body parts. The conversion channel can be used to implement virus scanning using third-party anti-virus products. For example, for OpenVMS, DEC CDA that is “hooked” into PMDF. Also for OpenVMS, supported conversions include: the DEC CDA Library, KEYpak from ANE Resources, Inc., WPS+ and DX to ASCII, and user-written conversion programs. PMDF can run the file through virus scanning software automatically prior to delivery of mail.
  • Directory - for the delivery of messages based on mapping envelope addresses using PMDF databases, LDAP directory look ups, or CCSO/qi/ph look ups.
  • Disclaimer - for adding a disclaimer notice to messages. The disclaimer channel can be used to prepend or append any text to plain or HTML messages or body parts.
  • Local - for delivery to OpenVMS Mail mailbox, BSD-style mailboxes on Linux, PMDF popstore mailbox, or MAIL-11 over DECnet. The PMDF SEND utility is included for message submission from the command line.
  • Phonenet - for delivery of messages over asynchronous dialup lines.
  • Pipe - for message delivery via a site-supplied program.
  • SMTP - for delivery of messages over TCP/IP.


Authentication Control

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.


Message Servers

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.


Automated Message Handlers

Message Filtering

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.


Directory Coordination Tools

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:

  • cc:Mail
  • LDAP Directories
  • HPE’s DDS
  • Lotus Notes
  • HPE’s OfficeServer
  • Microsoft Mail
  • GroupWise
  • PMDF Databases

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.


Circuit Check

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.


LDAP Integration

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.


Logging Capabilities

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.


PMDF Configuration

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.


OpenVMS User Agents

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.


DELIVER Facility

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.


Standards and RFCs

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
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
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
IMAP4 Namespace 2342
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
Message Submission 2476
Gateways and MIME Security Multiparts 2480
Using Digest Authentication as a SASL Mechanism 2831
Sieve: A Mail-Filtering Language 3028


Hardware Requirements

PMDF-MTA supports any valid OpenVMS or Linux configuration.


Software Requirements

One of the following operating system environments is required:

  • RedHat Enterprise Linux 6 or higher
  • OpenVMS Alpha 7.3 or higher
  • OpenVMS Integrity 8.2 or higher


Free Evaluation Software

Request a free evaluation copy of PMDF, or contact Sales directly for more information.