PMDF and Firewalls



A firewall system generally controls what TCP/IP interactions are allowed between the external world, considered to be unsafe, and an internal, protected environment, considered to be safe. The messaging component of a firewall could include many or all of the following components:

  • Spam protection
  • Protection against denial of service attacks.
  • Provide for address rewriting.
  • Control of who can send mail into and/or out of the firewall.
  • Filter mail on content, for example scanning attachments for a virus.
  • Limit internal information exposed to the external network
  • Provide substantial logging facilities for tracing.

Most firewall products available today provide functionality for one or two of these items, rarely all. Additionally, firewall products generally implement a small subset of the SMTP commands available and do not support ESMTP (Enhanced SMTP) features. As messaging emerges as a mission critical application, firewall products are increasingly inhibiting full messaging functionality between organizations. A good example is in the area of non-delivery notices (NDNs). Historically there has been an ad hoc mechanism for generating NDNs, but the IETF (Internet Engineering Task Force) has finalized a group of RFCs collectively referred to as NOTARY. NOTARY requires ESMTP support so that NDNs can be generated in the proper format. Proper NDN generation and receipt are crucial in knowing exactly what the problems are with the message not reaching its final destination.

PMDF, a full function SMTP server that implements ESMTP, can be used either in conjunction with a firewall or can be used on the firewall itself to dramatically improve the functionality and performance of a firewall for messaging. PMDF provides configuration tools to assist with either operating with a firewall or acting as a messaging firewall iteself.


PMDF on a Firewall

There are firewall products available that run on Unix operating systems. Generally the firewall vendor provides a version of sendmail for the SMTP server that has been heavily modified. The modifications substantially reduce the functionality in an attempt to make sendmail more secure. Historically sendmail has had many security problems. PMDF can replace that modified version of sendmail providing a secure messaging server and a great deal more features. PMDF has no relationship, history or code base with sendmail. PMDF has been engineered with security in mind, as such Process Software and our many of our customers have a great deal of confidence in PMDF’s ability to operate on a firewall.


PMDF in Conjunction with a Firewall

There are several ways to setup the operation of PMDF in conjunction with a firewall. Some of these recommendations may require features more common to a router using packet filtering techniques.

  • Let the firewall operate as an SMTP relay, but have PMDF front end it on the internal side of the network. This requires all internal mail systems to route mail destined for the external network through PMDF. Then, configure PMDF to route all mail destined for the outside network to the firewall, hence the firewall will handle delivery to the outside network. Also, the firewall will need to be configured to route all mail destined internally through PMDF. The disadvantage of this model is that the firewall is active in the mail delivery process. This means that the nice scaleable performance of PMDF will be hindered by the performance of the firewall. Also, many other features of PMDF will be limited to the internal network, like NOTARY, preventing service denial attacks and implementing some Spam blocking techniques.
  • Allow connections from all external systems through the firewall to the PMDF system directly on port 25 only. Implementing this will require packet filtering capability to limit connections only to the PMDF system for port 25 (the SMTP port). All messaging to and from the external network would be routed through the PMDF system. This delivers all of the features of PMDF and consolidates two points of message handling to one, which reduces overhead in problem determination.
  • Put a PMDF system outside the firewall and allow it access to your internal systems only on port 25. Again, all messaging to and from the external network would be routed through the PMDF system. This provides the same functionality as above, with the notable difference being that the system is not protected from attack by the firewall. Keep in mind that in this case the PMDF system, vulnerable to attack, will necessarily have quite a bit of configuration information about the internal network.
  • Put a PMDF system on both sides of the firewall. The external system will receive mail from the external system and relay messages to the internal PMDF system. This is most preferred for control and security as the access through the firewall is between two well defined systems. In this case, the system outside the firewall will have almost no configuration information about the internal network


General Issues to Consider

PMDF is a high performance MTA (Message Transfer Agent). If a customer chooses to allow or require the firewall take an active role in handling of messages, the firewall will most likely become a bottleneck for sites that have large message volumes. PMDF’s performance is very dependent on the underlying hardware and how PMDF is configured, Process Software is always willing to give advice on how to configure PMDF. Sendmail, and heavily modified versions of it, typically will hit a maximum performance limit well before the hardware is taxed. Said another way, regardless of the size of the system you put sendmail on you will never get sendmail to process more than 10 messages per second. As a comparison, PMDF has been tested on a very large system at over 150 messages per second.


General PMDF Functionality Useful for Firewalls

Dealing with Spam

There are many ways to try to fight spam. One of the most successful is to identify the source of the connection as it is made to PMDF and verify that the mail from address matches some portion of the domain the connection is being made from. If you put a firewall between PMDF and that incoming connection, the opportunity to determine where that connection originated from is now lost.


Deal with Service Denial Attacks

Unfortunately on the Internet, there are those folks who target certain companies or domains and try to cause problems for the normal operation of Internet based services. Process Software, being sensitive to these types of events, has some built in facilities to help with this as well as a documented API so that a customer could apply their own heuristics. For example, PMDF allows for the definition of a maximum message size. This will prevent someone from sending messages that are hundreds of megabytes in size that would fill up the disks on your messaging systems.


Address Rewriting and Centralized Naming

PMDF provides generalized facilities to rewrite addresses into what we refer to as centralized naming. Process Software encourages customers to choose a centralized naming scheme, like This accomplishes several important functions like providing easily remembered and identifiable addresses, insulating against the headache of moving users to different mail systems (email address portability if you will) and sometimes most importantly not divulging to the outside world any details of your internal network.


Access Control

PMDF provides several algorithmic access control mechanisms to assist in limiting use of PMDF's services. For example PMDF has a SEND_ACCESS facility that, based on the FROM address, the source channel that the message entered the PMDF system, the TO addresses and the destination channel of the message, can be configured to constrict the flow of messages. So for example, if a company decides that only certain addresses are allowed to send outbound email but inbound mail is not restricted, this could be easily be accomplished using the SEND_ACCESS facility. PMDF also provides the ability to explicitly allow or disallow connections to its server facilities. So if a customer does not want to receive mail from the domain, there is PORT_ACCESS facility that can be used so that PMDF will not even accept a connection from any system in the domain. These are small examples of what PMDF can do in this area.


Conversion Channel

PMDF provides a general purpose conversion channel. Generally the conversion channel is used in conjunction with document conversion utilities such that when a WordPerfect document was received as an attachment that PMDF could call out to the conversion utility to convert the attachment to a Word document before passing it on. The conversion channel can also be used to scan a binary attachment or body part for a virus using a virus scanning software. PMDF can be configured so that if a virus is found that the body part is replaced with a text body part informing the recipient that the binary part was removed because it was infected with a virus or the virus can be removed and the attachment passed on.


Limiting Information Exposed to External Networks

There are two general ways that a site may consider limiting information exposed to the external network, one is information exposed in headers and the other is information that may be obtained from probing the SMTP server. For example using VRFY and EXPN, someone could determine who may or may not be able to receive mail and what addresses are on a mailing list. PMDF provides facilities to provide generic, non-informative answers to these types of probes.

When messages transit various mail systems, there are header lines added to the mail message so that the path of the message can be traced. These header lines are referred to as received headers. This header information is very helpful in problem determination, but this very same information can expose information about the internal network that some customers are uncomfortable with. PMDF provides facilities for a site to strip these received headers from the mail message, there is support to strip other headers as well. Process Software recommends careful consideration in this area. For example if a site requires header information to be removed, configure PMDF to strip that header information only to mail being passed to the external network. This will preserve header information until the last possible moment and will not remove the header information for mail that PMDF handles for the internal network.


Configurable Logging Facilities

One of the tasks that a postmaster, the person responsible for email, is often called upon to perform is to verify that a specific message was sent or received. The only way to do this is by examining log files. How many systems a postmaster has to examine, what type of logging facilities are available and how those log files are managed can be an issue. PMDF allows the customer to select the level of detail that gets logged and provides automated tools to manage the log files as well as provides hooks for a customer to customize management of the logging facilities. PMDF creates log files in a standardized format, so using databases and report writing applications to generate statistics is rather trivial for a customer to accomplish.