SMTP Proxies

In my previous article, I demonstrated the configuration of several HTTP proxies. In this article, I'd like to finish up the proxy series by concentrating on an example
SMTP proxy.

SMTP Proxies

Similar to an HTTP proxy, an SMTP proxy is used to add to the feature set
already provided by your MTA, or mail server. Again, the amount of available
configurable features will vary, depending upon the specific mail server
software you've chosen to use in your environment.

The advantage of an SMTP proxy may lie in its ability to simplify your
configuration. A web browser's configuration isn't that hard to figure out;
simply play around with the available options in the Preferences menu. An SMTP
server is a much more complicated piece of software. Finding and making
configuration changes can involve reading reams of documentation and dealing
with databases, macros, and multiple configuration files.

When dealing with email, one is usually concerned with controlling spam and
viruses. Due to the prevalence of both email and the nasties associated with
it, it's not surprising that there are myriad supporting applications available
to a mail server administrator. This further increases the complexity. For
example, one could install and configure a virus scanner, a separate
application to tell the SMTP server to use the virus scanner, and yet another
application to check for the possibility of spam.

A good SMTP proxy simplifies this configuration process. Remember, an
application proxy scans the data portion of a packet. What better time to look
for viruses and spam?

Building and Installing messagewall

I've chosen to demonstrate messagewall. I like this SMTP proxy, as
it has many configurable features with a straightforward and very user-friendly
configuration. Without further ado, let's become the superuser and build this
port:

%cd /usr/ports/mail/messagewall
% make install clean

At the beginning of this build, the following message will go by:

You may use the following build options:
-DMESSAGEWALL_ALLOW_MULT_RCPT to allow multiple recipients. The profile
for the first recipient will be applied to all recipients of the message

If you're ever building a port and notice a message and want to use that
extra option, simply press Ctrl-D to stop the build, and start it
over again with the option:

% make -DMESSAGEWALL_ALLOW_MULT_RCPT install clean

It is a better idea to check first for any possible options, like so:

$ more Makefile | grep ECHO
@${ECHO} ""
@${ECHO} "You may use the following build options:"
@${ECHO} ""
@${ECHO} " -DMESSAGEWALL_ALLOW_MULT_RCPT to allow multiple recipients"
@${ECHO} " The profile for the first recipient will be applied to all"
@${ECHO} " recipients of the message."
@${ECHO} ""

Once the build is finished, another message will go by. If you missed it,
you'll always find such messages in a file called pkg-message.
These messages usually contain configuration information, so it's always a good
idea to read a port's pkg-message.

I'll go through messagewall's pkg-message, as some
of the commands work on a Linux box instead of your FreeBSD box. Also,
messagewall works in a chroot. If you're unfamiliar
with the term chroot and why it is a good thing, check out this introductory
article.

messagewall also requires you to create two user accounts, two
group accounts, and the directories to be used by the chroot.
Let's take a look at pkg-message and follow the instructions:

$ more pkg-message
Messagewall has been installed, now create the chroot environment:
mkdir /home/mwall

The next instruction says to create a group using groupadd and
a user using useradd. Since FreeBSD doesn't use those commands,
use pw instead:

Finally, copy the included virus patterns into your chroot environment:

% cp /usr/local/etc/messagewall/virus.patterns /home/mwall

The final instruction is:

and don't forget to edit your configfile!

One way to find out the name of that installed configfile is to search for
it in the port's pkg-plist:

$ more pkg-plist | grep conf
/etc/messagewall.conf.sample

By default, all port directories start at /usr/local, so the
location of this configuration file is really
/usr/local/etc/messagewall.conf.sample. Since this is a sample
configuration file, we'll start by copying it to the real configuration file
we'll edit:

Configuring messagewall

Now use your favorite editor to open up the configuration file. You'll
note that everything is commented out, so the message wasn't kidding when it
told you to edit the file first. The nice thing about this configuration file
is the clear, readable comments. Every option is commented, and optional
options are clearly labeled as OPTIONAL.

I'll walk through the configuration file with you, pointing out things to be
aware of.

# This is the MessageWall sample configuration file. All
# variables in this file must be uncommented and defined before
# MessageWall will start.

This comment is fairly clear. Since most of the defaults are reasonable, I
will simply uncomment the following:

As you go through your configuration file, read each comment and decide for
yourself if your particular situation requires different values than the
defaults. When in doubt, stick with the default value.

Now come some values that need to be customized for your installation.
First, give the IP address of the machine running messagewall:

# The IP address, in dotted quad notation, that MessageWall should
# listen on. As MessageWall will bind to port 25 on this address, it
# will need to be run as root.
#
listen_ip=1.2.3.4

Next, the IP address of the SMTP server. This may or may not be the same
machine as the one running messagewall:

# The IP address, in dotted quad notation, that MessageWall should
# connect to in order to deliver messages that have passed filtering.
# MessageWall will connect to this IP address on port 25 and speak
# ESMTP or SMTP. The server running on this IP should support ESMTP,
# PIPELINING and 8BITMIME, but does not need to. You may chain
# MessageWall installations in order to spread filtering across
# different systems, although this is highly inefficient.
#
backend_ip=127.0.0.1

Next, the name of your company. Typically, this is the name used in the MX
record of your DNS database.

# The primary domain name that MessageWall is serving. This is used
# in several SMTP responses.
#
domain=example.com

This is followed by several other options that you may wish to leave at the
default values as you uncomment them, unless you're a real SMTP guru:

Profiles and Viruses

Each profile is an ASCII text file that contains a set of rules indicating
what messagewall should look for when it is reading the data
portion of a packet. The configuration file uses the Medium
profile by default, which looks like this:

Note that the file is composed of variables followed by values. Explanations
of each variable and examples of possible values are given in man
messagewall_profiles. Most of the values are straightforward. For
example, the filename_reject variable indicates which attachments
should be discarded. In this profile, any attachment with an extension of
exe, pif, scr, vbs,
bat, com, shs, or wsc will
be rejected. One could easily follow the format and add his or her own lines for
extensions that should also be rejected.

If you've ever configured a spam filter such as procmail,
you'll recognize the header_rejecti variable. The values indicate
what to look for in an email message's header. If that value is found, the
message will be rejected as spam.

Unsurprisingly, the virus_scan variable tells
messagewall to scan for viruses as long as this value is turned on
or set to 1. You should note that, like all SMTP proxies,
messagewall relies upon a separate virus-scanning product.
messagewall follows the Open AntiVirus format.

Remember copying the default virus patterns earlier? These virus definitions
will get you started, but you will still want to download the latest virus
definitions. If you're the curious type, the format is in ASCII text,
meaning you can take a look at the virus definition file.

Before we leave the default profile, you should take the time to check out
the settings in the other available profiles. If you find a profile that is
better suited to your network's needs, don't forget to edit
messagewall.conf to reflect the desired profile.

messagewall must be started as root in order to bind to the
specified address on port 25. However, once the port is bound, it will enter
the chroot and assume the identity of the mwall user.
Note that you'll lose your prompt when you start messagewall and
will see a series of messages:

Other Utilities

Finally, there are two other utilities that were installed with
messagewall. messagewallctl is used to interact with
messagewall once it is running. It has its own manpage; type
messagewallctl to receive its list of possible commands.

Virus definitions are usually updated on a daily basis. You'll need to make
messagewall aware that the definitions have changed, but you don't
want to stop the service in order to do so. Instead, simply type:

% messagewallctl reload-virus

This is the most common usage of messagewallctl. Refer to its
manpage to see its other usages.

The other utility is messagewallstats. To use this handy
utility, first create an empty file to hold the statistics. I've decided to
create one in the chroot:

% touch ~mwall/messagewallstats

Then start messagewall, telling it to redirect its statistical
output to this file:

% messagewall > ~mwall/messagewallstats

Now, whenever you want to view the statistics:

$ messagewallstats ~mwall/messagewallstats | more

As you can see, I was pretty anxious and viewed my stats before any email
actually arrived and had a chance to be acted upon by
messagewall:

This should get you started with messagewall. For further
information, there is an FAQ and an archive of the mailing lists at the messagewall home page.

Dru Lavigne
is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.