Run a Business Network on Linux: SMTP Forwarding

Carla SchroderVirtually all servers have an option to email reports, logs, and alerts to the server administrator. You can use a standard heavy-duty MTA (mail transport agent) like Postfix, Sendmail, or Exim, but that’s overkill. A simpler, more lightweight solution is to use a specialized relay-only MTA that has only one job: sending messages from your servers to an external mail server. This can be a local server on your LAN, a remote mail server way across the Internet, or even a Gmail account. There are several advantages to doing this: using fewer system resources, simpler configuration, less possible conflict with other mail servers, fewer potential security holes, and messages from multiple servers going to convenient locations.

There are at least a dozen of these floating around; we’re going to use sSMTP on our Ubuntu Server 8.04, because it’s very easy to use. Another similar relay-only MTA is nullmailer, which is also easy to use. Neither one is capable of receiving mail, so you don’t have to worry about open ports. A possible drawback to both of these is they don’t perform local mail delivery on the server itself — all they know how to do is relay to a remote mail server. esmtp-run plus Procmail is a good candidate for admins who want both an MTA relay and local delivery.

Getting Rid of the Fat

It’s a good practice to keep servers as lean as possible. Most Linux distributions default to having some kind of MTA installed because a lot of applications depend on an MTA. Ubuntu defaults to Exim4, which is included in the base installation. Just for fun, run apt-cache rdepends exim4 to see how many applications have the <mail-transport-agent> dependency. This also shows you a list of MTAs that will satisfy this dependency—you’re not stuck with the default.

One thing you can do to keep your system slim and trim, without losing anything important, is to make sure apt understands that you only want dependencies installed, and not recommended or suggested packages. Ubuntu’s default configuration does this:

  • Installs recommends for all metapackages
  • Does not remove unneeded dependencies when metapackages are removed
  • Requires manual removal of kernels and kernel modules

You can see all of this in action in the files in /etc/apt/apt.conf.d/. 01autoremove, 01ubuntu, and 05aptitude control this behavior. You might want to copy these to a different directory in case you want them again. To change to installing only dependencies and automatically removing unneeded dependencies when you remove packages, make these files look like the following examples. 01autoremove should have only these lines:


        Install-Recommends "false";
        Install-Suggests "false";

If you want old kernels and modules to be automatically removed when new ones are installed, then delete the NeverAutoRemove stanza. Or you may comment out the lines using forward slashes, like this:

//  NeverAutoRemove
//  {
//        "^linux-image.*";
//        "^linux-restricted-modules.*";
//        "^linux-ubuntu-modules-.*";
//  };

Some folks consider this to be a bit risky- if there are problems with a new kernel, having an old proven one hanging around means you’ll still be able to use your system.

Move 01ubuntu to another directory:

[email protected]:/etc/apt/apt.conf.d$ sudo mkdir oldfiles
[email protected]:/etc/apt/apt.conf.d$ mv 01ubuntu oldfiles/

Then add these lines to 05aptitude:


I prefer aptitude to apt-get because it handles dependency resolution more intelligently. Whatever package manager you like, now all your bases are covered. For complete apt.conf.d examples, read /usr/share/doc/apt/examples/configure-index.gz:

$ zless /usr/share/doc/apt/examples/configure-index.gz

Installing sSMTP

When you install a new MTA on an existing system the old one must be removed, which is the reason for the lesson in package management. This is how it looks with the default Exim4 present:

$ sudo aptitude install ssmtp
The following actions will resolve these dependencies:

Remove the following packages:

Score is -819

Accept this solution? [Y/n/q/?]

Say yes. After installation you’ll have two files to edit, /etc/ssmtp/revaliases and /etc/ssmtp/ssmtp.conf. I want messages to go to my [email protected] account, so /etc/ssmtp/revaliases needs this line:

root:[email protected]

[email protected] is an account that already exists, and this example uses the fictional hosting service You want to use fully-qualified domain name of your mail server, which you can get from your service provider or local admin, and if the local admin is you then you’re all set. Not only will all of root’s mail go to [email protected], but also all messages for the user IDs under 1000, so all of the UIDs for every service on the system are covered.

Now /etc/ssmtp/ssmtp.conf needs some information:

[email protected]

This sends all mail to [email protected] via the specified mail server, the return address is rewritten to whatever domain name you want, and the hostname must be the real FQDN of your server.

Different Domain Name

rewriteDomain is important, so let’s dig into it a bit more. Thanks to spammers, email service providers long ago closed off open relays and usually perform domain checking. This may affect you depending on how your mail server is set up. My ISP requires that all outgoing SMTP traffic pass through its servers, so even though I own a few domains and have control of my own mail servers, I cannot send my outgoing mail through it. My ISP’s policies are fairly liberal— they don’t require authentication, and I can use any return address I want, as long as it resolves to a real domain. But if I try to use a non-registered domain name like, which I use only for my private internal network, messages get bounced:

send-mail: 553 5.1.8 <[email protected]>... Domain of sender address [email protected] does not exist

So instead I use one of my domain accounts. /etc/ssmtp/revaliases looks like this:

root:[email protected]

And /etc/ssmtp/ssmtp.conf looks like this:

[email protected]

What if your mailhub requires authentication? No problem, because sSMTP supports SSL/TLS and password authentication, as this example shows:

[email protected]

If you’re dealing with a super-secure mail server that requires peer authentication using a certificate authority, you can specify which certificate to use:


Testing sSMTP

Install the mailx package so you’ll have the mail command. This is a very useful command-line mail client that lets you test your mailservers and see exactly what is happening. Use this simple invocation on your server to send a test message, and I’ll show the complete output:

[email protected]:~$ echo "this is an sSMTP test" | mail -vs "test1 ssmtp" root
[<-] 220 ESMTP Sendmail 8.13.1/8.13.1; Fri, 20 Jun 2008 11:20:32 -0700
[->] HELO
[<-] 250 Hello [] (may be forged), pleased to meet you
[->] MAIL FROM:<[email protected]>
[<-] 250 2.1.0 <[email protected]>... Sender ok
[->] RCPT TO:<[email protected]>
[<-] 250 2.1.5 <[email protected]>... Recipient ok
[->] DATA
[<-] 354 Enter mail, end with "." on a line by itself
[->] Received: by (sSMTP sendmail emulation); Fri, 20 Jun 2008 11:20:33 -0700
[->] From: "alrac" <[email protected]>
[->] Date: Fri, 20 Jun 2008 11:20:33 -0700
[->] To: root
[->] Subject: test1 ssmtp
[->] this is an sSMTP test
[->] .
[<-] 250 2.0.0 m5KIKW1b003665 Message accepted for delivery
[->] QUIT
[<-] 221 2.0.0 closing connection

You can see the entire conversation here. If there are any failures they’ll be visible, and you should also look in the /var/log/mail.* files for troubleshooting. When I pick up my [email protected] messages, the return address will be [email protected]

If I want messages to go to a Gmail account, or any other account, all that’s necessary is to substitute a Gmail address for the [email protected] address; everything else remains the same.


Latest Articles

Follow Us On Social Media

Explore More