Welcome to the second part of my FreeBSD email server series. In this series, I will guide you through setting up your own email service. Be sure to done the preparations from part 1 of this series.
This part will guide you through setting up email service on your machine using Postfix. Basic installation is pretty straightforward, but there is a lot to configure. If you are not sure what some configuration options do, please read up on them. There is a lot to do wrong with a mail server, and doing things wrong will likely get you on a blacklist which will make other servers stop processing the mail you are trying to send out.
Setting up Postfix is one of the harder parts of configuring a mail server. If you have questions after reading the full guide, please find me on IRC. You can find details on how to do so on my homepage.
Installation procedures on FreeBSD are pretty straightforward. Unlike
from the previous part, we will need to compile Postfix from source in order to
use PostgreSQL as a database back-end. Thanks to FreeBSD’s
ports, this is not difficult either. If this is your first
port to compile, you probably need to get the ports tree first. You can
download and extract this using the following command.
Once that has finished running, go into the directory containing the build instructions for Postfix, and start the installation process.
This will open a pop up with a number of options you can enable or disable. The
enabled defaults are fine, but you will have to enable the
PGSQL option. This
will allow you to use the configuration tables created in part 1.
Enable the Postfix service for rcinit. This allows you to use
start once configuration is done, and will auto start the service on system
boot. In addition, the default mailer on FreeBSD, sendmail should
be disabled so nothing is in Postfix’s way when trying to deal with processing
There is a ton to configure for Postfix. This configuration happens in two
master.cf. Additionally, as some data is in the
PostgreSQL database, three files with information on how to query for this
information are needed. All of these files are in
The guide has a comment line for most blocks. It is advised that if you decide to just copy and paste the contents, you copy that along so you have some sort of indication of what is where. This could help you out if you ever need to change anything later on.
The configuration file starts off by setting the compatibility level. If postfix updates the configuration scheme and deprecates certain options, you will be notified of this in the logs.
These options indicate where Postfix will look and keep certain files required for correct operation.
The domain configuration instruct the server of the domain(s) it should serve
for. Use your FQDN without sub domains for
mydomain. You can use a sub domain
myhostname, but you are not required to. The most common setting is
All internet devices it should listen on, and all domains this server should consider itself the endpoint for, should be listed here. The defaults in the example block are good enough, as we put some of our data in the PostgreSQL database instead.
Reject unknown recipients
How to deal with messages sent to an email address whose domain points to your
server’s address, but have no actual mailbox. A code of
550 means to inform
the remote server that delivery is not possible and will not be possible. This
should stop the remote server from trying it again.
This block is optional. It allows you to use email address extensions. These are addresses with an additional character in them that will drop the email in the non extended address’ mailbox, but allows you to quickly filter on them as the sent-to address contains the extension.
Virtual domain directives
This part is where things get important. Virtual domains allow you to handle
mail for a large number of domains that are different from the actual server’s
domain. This is where the database configuration comes in to play. It is
important to note the
static:125 values. The
125 should map to the
postfix user account on your system.
The TLS setup configures your server to use secure connections. The keys used here have been generated in the previous part of this series.
SASL deals with the authentication of the users to your email server.
The debugging options are generally useful in case things break. If you have little traffic, you could leave them on forever in case you want to debug something later on. Once your server is working as intended, you should turn these options off. The postfix logs get pretty big in a short amount of time.
Installation time defaults
These options should not be touched, but are very important to have for your server.
master.cf file, you can use the following configuration block.
SQL query files
The following three configuration files deal with the SQL query files to make Postfix able of getting some of its configuration from a database. You obviously have to change the first 4 directives to match your database authentication credentials.
This should be enough Postfix configuration, for now. Next part involves Dovecot, which will enable IMAP. It will also provide the SASL mechanism defined in this part.