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.
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.
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
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.
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.
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.
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 Firstname.Lastname@domain.com.
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.
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 spam-mail.com, there is PORT_ACCESS facility
that can be used so that PMDF will not even accept a connection from
any system in the spam-mail.com domain. These are small examples of
what PMDF can do in this area.
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.
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.
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.
|
