Mail server configuration


Jump to: navigation, search



Sendmail is probably the most popular mail server in use on the Internet today and it's included in FreeBSD. In it's default configuration it's rather crippled though. It will only accept connections on the internal loopback interface for example. You can easily alter the configuration and turn Sendmail into a fully functional mail server. Some of the benefits are listed here:

  • An unlimited amount of email addresses which is perfect to use for temporary registrations on various web sites.
  • Can be configured not only to receive email for your DynDNS domain but also for additional free or commercial domains that you control.
  • With the pf firewall guarding the mail server you can prevent spammers from delivering their crap at all. No need for the clients to filter mail afterwards.


The very first thing you have to do is to make Sendmail listen on all available interfaces.

# echo 'sendmail_enable="YES"' >> /etc/rc.conf
# /etc/rc.d/sendmail restart
Stopping sendmail.
Starting sendmail.

Then there is a number of configuration files you need to either create or change to make this work so let's go through them one by one. Everything you need is located in /etc/mail so start off by changing to that directory.

# cd /etc/mail


This file controls who will be allowed to access this mail server and what they will be allowed to do. This file does not exist by default so create it and copy and paste the following lines:

localhost RELAY RELAY
192.168.69 RELAY

The last line contains your internal network so it has to be adjusted to match whatever you're using. That same line will give any computer on your internal LAN access to send mail to anyone on the Internet through your mail server. You can restrict this by specifying complete IP addresses instead, pointing only to those computers you trust.

After updating this file you have to compile it.

# make
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/   /usr/share/sendmail/cf/m4/cf.m4 >
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/   /usr/share/sendmail/cf/m4/cf.m4 >
/usr/sbin/makemap hash access.db < access
chmod 0640 access.db

In the final two rows of the output you can see that your access file is converted to access.db instead. Don't worry about the output before that. It will be explained further down.


In this file you find a list of userids that are normally in use by various services on the server. It also contains userids that are expected to be found on the server regardless of whether they have actually been defined or not. If anyone sends an email to these users, you surely would like to catch them and have them forwarded to your own userid and this is the purpose of this file. Remember to change the occurrence of the userid pp below to the userid you created for yourself on the router.

Find the following rows in the file:

# root: me@my.domain
# webmaster:    root
# www:          webmaster

Change them to:

root:   pp
webmaster:      root
www:            webmaster

What you have done now is to redirect all system mails to your own user account. Note the remark symbols that you have to remove and don't mistake them for a command prompt symbol. After updating this file you have to compile it.

# make
/usr/sbin/sendmail -bi -OAliasFile=/etc/mail/aliases
/etc/mail/aliases: 30 aliases, longest 10 bytes, 306 bytes total
chmod 0640 /etc/mail/aliases.db</pre>


Here you place the name of every domain you want this server to accept mail for. You can add as many as you like but you also have to make sure that those domains resolve to the IP address of your router or at least have an MX pointer that does. The file does not exist default so simply create it by adding your DynDNS domain.

# echo "" >> /etc/mail/local-host-names

After updating this file you need to restart Sendmail.

# make restart
Restarting: sendmail sendmail-clientmqueue.


This file is similar to the aliases file. To use a new email address for your domain you don't really have to create a user for it. If all you're looking for is simply a number of temporary email addresses to use for registrations here and there, it would be a lot of job having to create a user for each and every one of them and then connect to every separate account to read the mail. A simpler way is to define a virtual user and point it to an existing userid, exactly as you did in the aliases file. There are two approaches here: You could define a "catch-all" address, one single line in this file that would direct any incoming mail for your domain to your own account unless it matched an existing user of course. However, sooner or later you will experience a spammer who will create false sender addresses for all his spam using the name of your domain. When the majority of all that spam bounces at the receiving mail servers, where do you think they send their notices that the mail couldn't be delivered? I'm talking from personal experience here and it's not very funny waking up one morning finding tens of thousands of mail delivery failure notices in your mailbox and just seeing them continue flooding in. Well, to be honest I might have provoked one or two spammers into this by using some nasty tricks while blocking them. :-) But from this experience I recommend you instead define every virtual user specifically in this file. It's still much quicker than creating physical accounts. Below you find an example of some content you can put in this file. It also shows how you can block individual email addresses if they start receiving a lot of spam. Again, this file does not exist by default either so you'll have to create it first.         pp         pp        me@some.other.domain       pp           error:nouser No such user here  error:nouser You can put any offensive message you like here

If you're brave and still want to try the "catch-all" approach, here is the syntax you'll use in the file instead.                  pp

You need to compile this file too after changing it.

# make
/usr/sbin/makemap hash virtusertable.db < virtusertable
chmod 0640 virtusertable.db

*.mc and *.cf and are the two main configuration files for Sendmail. They are extremely versatile and modular and can alter many aspects of how Sendmail receive, process and deliver mail but the downside is that they're also extremely complex because of this. Like all other Sendmail configuration files these are compiled too and you never edit them directly. By default there is instead a and a which you edit and then compile to their respective .cf file. FreeBSD has chosen a slightly different naming convention though.

  • is called and is compiled to which in turn is copied to during installation.
  • is called and is compiled to which in turn is copied to during installation.

The first time you type make in /etc/mail you get another set of these files.

  • is copied to - in this example
  • is copied to - in this example
  • is copied to - in this example
  • is copied to - in this example and, named after your own domain of course, are the files you make changes to if you need to. Whenever you then type make install they will be compiled to their respective .cf files which are then copied to and respectively. What's the purpose of this complicated behaviour? Well, the FreeBSD template files, and possibly also the default configuration files, will most likely be overwritten every time you upgrade FreeBSD. If there weren't a set of intermediate configuration files you would loose your changes every time you upgrade. Instead it's up to you to merge any changes in the upgraded template files into your own configuration files and then compile new default configuration files for Sendmail whenever you perform an upgrade. Luckily it's not very likely you need to touch these files for a home router but I will show one change here that you probably will have to do.

Most ISPs that provide their services to home users usually block outbound traffic on port 25 which is used by mail servers to deliver mail to other mail servers. The intention is to prevent infected computers from becoming relay hosts for mail spam. This block effectively accomplishes that goal but it also blocks you from delivering your real mail directly to the receiving mail servers. Instead you have to tell Sendmail to deliver all outbound mail to your ISPs relay server and it will then make sure your mail reach its intended destination. If your ISP doesn't block port 25 you can skip to the next step.

Open your in your editor and locate the following row:

dnl define(`SMART_HOST', `your.isp.mail.server')

Change it to:

define(`SMART_HOST', `')

Of course you replace the relay server's name with that of your ISP's. Also take care when you erase the leading dnl on that row so you don't disturb anything else in the file. Exit and save the file and then type:

# make install
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/   /usr/share/sendmail/cf/m4/cf.m4 >
install -m 444 /etc/mail/
install -m 444 /etc/mail/

After installing the new configuration files you have to restart Sendmail again:

# make restart
Restarting: sendmail sendmail-clientmqueue.

Firewall rule

You have to add a rule to your firewall to allow incoming mail from the Internet to reach your server. Find the rule allowing ssh in the section # Incoming to router and add this rule after it:

pass in log quick on $ext_if inet proto tcp from any to ($ext_if) port smtp flags S/SA synproxy state queue (q_p1, q_p2)

Reload the firewall rules in the usual manner.

# pfctl -nf /etc/pf.conf
# pfctl -F rules ; pfctl -f /etc/pf.conf

Your Sendmail configuration is now finished and you now have your own fully functional mail server.

Open relay

As a new owner of a mail server you need to be aware of open relaying. Your mail server will become a prime target for spammers and they will try many tricks to make your server distribute their spam for them in an effort to hide themselves and put the blame for the spam on you. An open relay is a mail server that accepts mail from users not belonging to your domain and delivers it to users that also don't belong to your domain. This was they way mail servers were configured by default a few years ago and it was heaven for spammers. This has of course changed but spammers have over the years figured out many ingenious ways to get around the tighter security in modern mail servers. Sendmail is as secure as it can be though and isn't vulnerable to any of the known attacks that exist. This doesn't mean that there won't be any security issues in the future but for now you can feel pretty confident in your server. If you wish to test your server against known attacks, and at the same time see how ingenious some of those attacks are, you can use this free service over at

Reading your mail

Now when the server is up and running and collecting mail for you, wouldn't it be nice if you could access them and read them somehow? You may think that works automatically but where's the fun in that? ;-) No, you have to install a small application from Ports to act as a pop3 server so you can connect with Thunderbird or Outlook or whatever you normally use to read your mail.

There are several pop3 servers to choose from in the Ports Collection. For a full featured pop3 server supporting encrypted connections and everything, you should probably go for qpopper but the installation involves many advanced concepts so for now I will show you the much simpler popa3d. As usual there is a configuration screen for the compile options but you can leave them at their defaults.

# cd /usr/ports/mail/popa3d
# make
# make install clean

Note the output.

1. Edit your /etc/inetd.conf to use popa3d. The line should look like this:

pop3	stream	tcp	nowait	root	/usr/local/libexec/popa3d   popa3d

Note: when started via an inetd clone, the logging of connections is left
up to that inetd clone or TCP wrappers.

2. Restart inetd by sending it a SIGHUP:

# killall -HUP inetd

To save memory and other computer resources many services are not meant to run constantly. Instead they are executed only when they're needed and will exit as soon as they have provided whatever service was requested. For this to work you need some kind of mechanism to monitor the service ports and launch the correct application when needed. That mechanism is called inetd so you'll have to configure it to support popa3d. Load /etc/inetd.conf in the editor and find the following line:

#pop3   stream  tcp     nowait  root    /usr/local/libexec/popper       popper

Remove the # at the beginning of the line and change the end of it to match what was written in the output.

pop3   stream  tcp     nowait  root    /usr/local/libexec/popa3d       popa3d

Step 2 in the output is only applicable if you already have inetd up and running which you don't have at this point so you have to do this differently.

# echo 'inetd_enable="YES"' >> /etc/rc.conf
# /etc/rc.d/inetd start
Starting inetd.

Everything is now set up to retrieve your mail from the router but you have to configure your email client first. There's usually only four parameters you will have to enter: protocol - pop3; mail server - (that should be your router's internal IP address); the userid and password you configured for yourself on the router. Since the logon procedure is sending your password unencrypted it's not advisable to read your mail from the Internet side. The firewall is not configured to let that traffic through anyway but if you still want that option you'll have to add the following rule to your firewall configuration, after the other q_p1 rules in the section called # Incoming to router.

pass in quick on $ext_if inet proto tcp from any to ($ext_if) port pop3 flags S/SA synproxy state (q_p1, q_p2)

After that you have to reload the firewall rules again.

# pfctl -nf /etc/pf.conf
# pfctl -F rules ; pfctl -f /etc/pf.conf


  • Sendmail's configuration files are all located in /etc/mail.
  • The start/stop script for Sendmail is /etc/rc.d/sendmail but Sendmail should rather be restarted with make restart in /etc/mail.
  • Inetd is the super-server daemon that manages Internet services.
  • The configuration file for inetd is /etc/inetd.conf.
  • The start/stop script for inetd is /etc/rc.d/inetd.

Unresolved issues

Something I'm missing is a webmail interface to the server. An IMAP server is necessary and courier-imap seems to be the appropriate choice. But the installation is complicated with setup of encryption, changes to the and creation of a folder structure for all user's mail and it's interaction with the day to day user administration. I haven't found a good source of information to explain all the concepts clearly enough to not risk messing things up.


Next guide: Annoying spammers
Personal tools