BSD DevCenter
oreilly.comSafari Books Online.Conferences.


FreeBSD Basics SMTP Proxies

by Dru Lavigne

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:

% pw groupadd mwall
% pw useradd mwall -g mwall

Next, follow along and create two directories:

% mkdir /home/mwall/pids
% chown mwall:mwall /home/mwall/pids
% mkdir /home/mwalla

Substitute the pw command for the next user and group:

% pw groupadd mwalla
% pw useradd mwalla -g mwalla

One more directory:

% mkdir /home/mwalla/pids
% chown mwalla:mwalla /home/mwalla/pids

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

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:

% cp /usr/local/etc/messagewall.conf.sample /usr/local/etc/messagewall.conf

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.

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.

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.

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:


The next value needs to be changed, as it is incorrect. It should look like this:


We'll look at that directory and the concept of profiles once we're finished with this file. The next path is correct and can simply be uncommented:


For now, uncomment the next two profiles until we've had a chance to discuss profiles.


Next come the options, meaning you don't have to uncomment these if they aren't pertinent to your situation:


Hang in there, we're almost finished. Uncomment the lines for the user accounts you created and their home directories:


Finally, a few more options:


Once you're finished uncommenting your configuration file, save your changes. Now, let's take a look at that profile directory that was mentioned in the configuration file:

% ls /usr/local/etc/messagewall/profiles/ 
./		Light		Medium Plus	Relay		Warning
../		Light Plus	None		Strong
Extreme		Medium		Reject

Pages: 1, 2

Next Pagearrow

Sponsored by: