Run a Business Network on Linux: SMTP Forwarding

If your needs don't include a full-blown MTA, consider setting up an SMTP relay like small, simple sSMTP.

 By Carla Schroder
Page of   |  Back to Page 1
Print Article

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:

alrac@sonja:/etc/apt/apt.conf.d$ sudo mkdir oldfiles
alrac@sonja:/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 admin@mailhost.net account, so /etc/ssmtp/revaliases needs this line:


admin@mailhost.net is an account that already exists, and this example uses the fictional hosting service mailhost.net. 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 admin@mailhost.net, 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:


This sends all mail to admin@mailhost.net 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 alrac.net, which I use only for my private internal network, messages get bounced:

send-mail: 553 5.1.8 <alrac@alrac.net>... Domain of sender address alrac@alrac.net does not exist

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


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


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


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:

alrac@sonja:~$ echo "this is an sSMTP test" | mail -vs "test1 ssmtp" root
[<-] 220 mail.mailhost.net ESMTP Sendmail 8.13.1/8.13.1; Fri, 20 Jun 2008 11:20:32 -0700
[->] HELO sonja.alrac.net
[<-] 250 mail.mailhost.net Hello dsl-dhcp-494.mailhost.net [] (may be forged), pleased to meet you
[->] MAIL FROM:<alrac@bratgrrl.com>
[<-] 250 2.1.0 <alrac@bratgrrl.com>... Sender ok
[->] RCPT TO:<admin@bratgrrl.com>
[<-] 250 2.1.5 <admin@bratgrrl.com>... Recipient ok
[->] DATA
[<-] 354 Enter mail, end with "." on a line by itself
[->] Received: by sonja.alrac.net (sSMTP sendmail emulation); Fri, 20 Jun 2008 11:20:33 -0700
[->] From: "alrac" <alrac@bratgrrl.com>
[->] 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 mail.mailhost.net 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 admin@bratgrrl.com messages, the return address will be root@mail.mailhost.net.

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 admin@bratgrrl.com address; everything else remains the same.


This article was originally published on Jun 24, 2008
Get the Latest Scoop with Networking Update Newsletter