PMDF-MTA Software Product Description

• MultiNet
• PMDF Internet Messaging
• PreciseMail Anti-Spam
• SSH for OpenVMS
• TCPware
• VMS Authentication Module

Overview

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.

 

 

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.

 

Description

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.

 

Channels

• 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.

 

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.

 

MAILSERV

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 API

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
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
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