source
This long post contains a recipe for building a reasonably secure ubuntu 16.04 mail server on amazon web services, using postfix, dovecot and mysql, with anti-spam packages in the form of amavisd-new, clam antivirus, spamassassin and posgris. local users are virtual rather than system users. user and domain management is achieved through the postfix management web interface. webmail is provided by roundcube.
This is an updated version of the previous ubuntu 12.04 and ubuntu 14.04 mail server recipes. several people kindly helped fix bugs and make improvements to the original, so if you find a crash issue here, please let me know.
intro
building a linux mail server from scratch to your liking is a painful process unless you are one of the few people who does it day after day, there is no way around that fact. a mail server usually consists of a variety of different packages that separately handle smtp, pop/imap, local mail storage, and spam-related tasks – they all need to communicate with each other properly, they all have little novels instead of configuration documentation and there is no obvious best practice for how users are managed, how to store user data, or how to tie the different components together. there are a lot of different viable configurations to move mail between postfix and dovecot, for example. furthermore, the whole set tends to be unforgiving on issues like file ownership and permissions, choosing users for specific processes, and small bugs in esoteric configuration files. unless you know what you’re doing, the end result is likely to be unsafe or subtly non-functional. just not working is perhaps the best of bad results.
You should also pay attention to adding support for the industry’s dominant spam suppression and deliverability tools, such as sender policy framework (spf) and domain key identified mail (dkim), or else you risk mail from your server being marked for the spam folder or invisibly discarded by many email providers. this is a broad topic and a changing ecosystem worthy of a lengthy case study in and of itself.
There are several fairly up-to-date recipes for creating mail servers; one of the best is an ubuntu recipe by ivar abrahamsen, which gives you postfix for smtp, courier for imap/pop, mysql for storing account information, virtual user mail directories, and a variety of anti-spam tools that are highly effective when working in concert. is a good set of documents, as the author puts an emphasis on producing a secure mail server as the end result. I’ve made good use of abrahamsen’s guide in the past as a basis for my mail servers and recommend it.
There are also a lot of partial recipes and outdated guides which, frankly, are more of a hindrance than a help, especially when it comes to pigeon loft, which has changed a lot between its 1.* and 2.* versions. the configuration is completely different, as are many of the administrative and tool binaries. When I chose to migrate my courier servers to dovecot in 2012, it was a challenge to find a good comprehensive guide, hence the existence of the first in this series of documents. I have since added new versions as ubuntu updates its long term support releases.
You should at least skim through the entirety of this post before you start following your recipe. that should help avoid any unpleasant surprises, and there are some notes at the end about alternative options and additions that are worth reading before starting.
outline the goal
The end result of following this guide will be a secure mail server for your domain equipped with the following software packages:
- postfix: send and receive mail via the smtp protocol. it will only relay mail to other mail servers if mail is sent by an authenticated user, but anyone can send mail to this server for local delivery.
- dovecot – a pop and imap server that manages local mail directories and allows users to log in and download their mail. also handles user authentication.
- postgrey – Greylists incoming mail, requiring unknown deliverymen to wait a moment and then resend it. this is one of the best tools to reduce spam.
- amavisd-new: a manager to organize various antivirus and spam checking content filters.
- clam antivirus: a suite virus detection .
- spamassassin: to detect spam in emails.
- postfix admin: a web interface to manage users and mail domains.
- roundcube: a webmail interface for users.
The server will accept plain text or encrypted smtp and pop/imap connections on the standard ports, but will not allow user authentication without encryption. will pass through a minimal set of mail headers for mail sent by local users, removing the original sender’s mail software identifying information.
using amazon web services
This post is written assuming the use of amazon web services to host a virtual mail server, but in theory any hosting service can be used. Very little of the material here refers to Amazon-specific issues. so if you’re working with another service, simply skip the aws-specific instructions and perform the equivalent operations on the service you chose to use. Keep in mind, however, that not all hosting services are created equal when it comes to how email providers view mail that comes from their server. for example, there is no point in even trying to host a major mail service on digital ocean: your ip ranges are blacklisted by many services, and you will have no influence with any of the parties involved when it comes to ensuring delivery. /p>
If not configured in aws, at least make sure you properly secure your server from the start. For many services, a new server or virtual instance is completely exposed to the internet, so you’ll want to immediately block it with something like a no-fuss firewall (ufw). for example, as shown below, replacing my_ip_address with your ip address:
after you have completed the setup, you can open your server as appropriate to allow you to communicate with the rest of the world.
use of example.com and mail.example.com
Throughout the instructions in this post, example.com is used as the domain, and the mail server for this domain has the hostname mail.example.com. so wherever you see these items, be sure to replace them with your chosen mail server domain and hostname.
start a ubuntu 16.04 aws instance with a proper security group
start a new server instance. at the time of writing ubuntu 16.04 is one of the options right there in the quick boot menu to start a new instance. Mail servers generally don’t have to be that big if you’re not in the email business: 2g of ram is enough for the recipe here, and that amount is needed only because clamav and amavis are memory hogs. so, while micro instances are too small, any of the larger instance types should be more than enough to support a personal mail server, a small business mail server, or the performance of a mailing list. a few thousand members.
Firewall configuration in aws is managed by assigning security groups. you’ll probably want to create one before you start the server. the security group must allow incoming tcp traffic from any ip address to these ports:
- 25 (smtp)
- 80 (http)
- 110 (pop3)
- 143 (imap)
- 443 (https)
- 465 (smtps)
- 993 (imaps)
- 995 (pop3s)
The above is in addition to any rules you may have for ssh access over port 22; it’s not a good idea to leave that open to the world, so close it to the ip address ranges you use. in fact, it’s a good idea to restrict all incoming traffic to the server to your own ip addresses while you build it. you can adjust the rules to allow traffic from the rest of the world once you are sure everything is safe and in order.
some basic configuration
the basic instance of ubuntu is missing from almost every package you might need, so you’re building almost from scratch. you will login as user “ubuntu” and then switch to root user via traditional “sudo su” command; most of what you need to do requires root access:
You must configure an elastic ip to give your server a permanent ip address. by default, an aws instance will have its own weird-looking hostname, so changing to the domain that the server will have is the first item on the list.
now set the content of /etc/hostname to be the hostname:
and add your hostname to the first line of /etc/hosts:
You will now want to regenerate the server’s default self-signed ssl certificate to match the domain name. You may have purchased an SSL certificate for your mail server, but it’s perfectly possible and completely safe to run a mail server using a self-signed certificate. the only consequences will be warning screens when using server-hosted webmail and microsoft outlook warnings when connecting via pop, imap, or smtp.
now create a lamp web server
The list of goals here includes webmail and a web-based administrative interface for managing users, so as a starting point you’ll need to set up a lamp web server, which means linux as the operating system, apache as the web server. , mysql as database and php as programming language. Fortunately, there is a shortcut to installing all the base lamp packages, so start by updating the repository data and installing those packages. note the “^” character at the end of the following command as it is required:
During this installation process, you will be prompted to enter and confirm a password for the mysql root user. choose something sensible and wait for the remaining installations to complete. you can then go on to add a number of additional necessary or useful packages to php, such as mcrypt support, curl, an xml parser, and gd image processing support. Note that the previous apc bytecode cache standby is no longer needed as this functionality is now part of the php core. at this point add more packages to suit your taste and to support any other applications you want to run on this server.
configure php
The default configuration settings for php and the additional packages mentioned above, found in /etc/php/7.0/apache2/php.ini and /etc/php/7.0/mods-available respectively, are sufficient for the more casual use. so unless you have something complicated or powerful in mind, there is no need to change anything.
use openssl to create a unique diffie-helman pool
These days, good security requires more and more work from system administrators. One of the newer attacks on SSL is known as logjam, and defending against it requires what is currently a non-standard addition to the application’s SSL configuration. creating your own strong diffie-helman group and saving it to a config file is the first step:
configure apache
The expected end result for the Apache web server is that it will serve a single site with a couple of web applications running: (a) roundcube for webmail and (b) postfix admin hidden in a subdirectory. all http requests will be redirected to use https, as there is no good reason to allow insecure access to any of the applications that will reside on the server.
first, configure the following lines in /etc/apache2/conf-enabled/security.conf to minimize the information that apache provides in its response headers:
make sure mod_rewrite, mod_ssl, some other useful modules and the default ssl virtual server are enabled; you’ll need these line items in order to force visitors to use https.
edit these lines in /etc/apache2/mods-available/ssl.conf to make sure no longer secure protocols are used:
The default site configuration in /etc/apache2/sites-available/000-default.conf can be edited to look like this for simplicity:
but of course your tastes and needs may vary. Keeping the same simple approach, the top part of the ssl configuration in /etc/apache2/sites-available/default-ssl.conf can be configured as follows:
If you’re using a purchased ssl certificate instead of a self-signed one, you probably also have a bundle of ca certificates from the issuer. If you don’t want to pay for a valid SSL certificate, you should consider setting up with Let’s Encrypt or a similar free CA initiative. you can have a wildcard certificate for *.example.com, a less expensive certificate that covers multiple subdomains like www.example.com and mail.example.com, or you can have separate certificates for the subdomains you’re interested in. place the relevant certificate, private key, and ca certificate bundle in the following locations:
- /etc/ssl/private/example.com.key
- /etc/ssl/certs/example.com.crt
- /etc/ssl/certs /ca-bundle.crt
the key must not be password protected and must be locked so that only the root user can read it:
now change these lines in /etc/apache2/sites-enabled/default-ssl.conf:
To push visitors to https, place something like the following snippet in /var/www/html/.htaccess:
make use of that diffie-helman group
The configuration required to use the diffie-helman group in /etc/ssl/private/dhparams.pem depends on the version of apache. for the version used in ubuntu 16.04, add or edit this line in /etc/apache2/mods-available/ssl.conf:
now restart apache to pick up the changes, after which you should be able to load the default apache home page and see that you are automatically redirected to https.
install mail server packages
now we are ready to start with the more difficult things. As for the lamp server, there is a shortcut to install the basic packages for a mail server. again, notice the “^” at the end of the command:
When postfix is installed, you will be prompted to choose a general type of mail configuration. At this point, select the website. you will be prompted for the system mail name, which is the host name of your mail server, e.g. mail.example.com. when dovecot is installed, you will be asked if you want to create an ssl certificate. here answer no as you will adjust dovecot configuration later to point to your default snake oil certificate or ideally your purchased ssl certificate.
what this set of packages gives you is pretty much the basics, aimed at setting up a mail server that handles your users as simple unix users and doesn’t use a sql database to store data. that’s not the point here, so we need the rest of the cast, like mysql support for postfix and dovecot, and a clique of spam packets:
amavis requires the libdbi-perl and libdbd-mysql-perl packages. the php7.0-imap package actually provides support for pop3 as well as the imap protocol, and will be needed by the postfix manager and most possible options for php webmail applications. you’ll want to restart apache at this point to have php7.0-imap running and you’re good to go:
Next, you’ll want to install some optional packages that extend the capabilities of the spam and virus detection packages by allowing further inspection of attachments:
configure mysql
Some modifications to the default mysql configuration in /etc/mysql/mysql.conf.d/mysqld.cnf are required. add the following:
then restart mysql server:
create a mail database and user in mysql
Login to mysql as the root user, entering the password you set earlier:
Now set up a database and user for the mail software. this database will store information about user accounts and mail domains, using the scheme established by the postfix administration pack. you’ll want to choose a better password than the example used below, but keep in mind that it will be entered into numerous configuration files. if an attacker gains shell access to the server, it doesn’t matter how good the password is. protection against unauthorized database access is largely provided by the firewall restricting access to mysql, but it never hurts to have good passwords regardless – implementing multiple layers of defense is always a good strategy .
install postfix admin 2.93 and mysql schema
postfix admin is installed as follows. To get started, download the sourceforge package, unzip it, move it to a subdirectory of your web root, and change ownership to the user www-data:
The next step is an interesting type of two-stage setup process. first create a new empty file /var/www/html/postfixadmin/config.local.php:
Entries made in /var/www/html/postfixadmin/config.local.php will override the default settings in /var/www/html/postfixadmin/config.inc.php. add the following lines:
Note that the last items above are just for defining how the postfix manager stores your data; they do not set system paths for mailboxes. the actual system paths to the virtual mailbox directories are defined in the dovecot configuration described in a later section of this post. there are many more configuration options related to optional functionality that can be used in the postfix manager. it’s worth exploring the documentation and the main config file /var/www/html/postfixadmin/config.inc.php.
then open a web browser and visit your mail server at:
the postfix manager will automatically create your database schema at this point. follow the instructions on that page to choose a setup password and generate a hash of that password. add that hash to the /var/www/html/postfixadmin/config.local.php config file and save it:
then return to the configuration page. you can now use the password you selected to create an initial administrator account.
create domain and accounts in postfix admin
now navigate to the main postfix admin login page:
Log in with the newly created admin account and then choose the domain list -> new domain option to create the example.com domain. Be sure to check add default email aliases, and note that you’ll probably want to change the default limits to allow unlimited aliases and mailboxes. then go to domain list -> list of domains and click on your domain name to view it. From that page, you can add mail users (add mailbox) and aliases (add aliases). this will populate the schema, but will do nothing else at this point since none of the other mail server components are configured to use the database.
make sure to create a mailbox for admin@example.com as your default aliases are redirecting to that address. Although alias addresses tend to get spammed, it’s a very good idea to pay attention to legitimate mail arriving at these addresses, as it can alert you to problems. this is less important for a personal mail server, but very important if you are sending mail and want to maintain good deliverability.
postfix admin has another useful function during this long configuration process: it allows you to send mail to local users through the web interface, which is useful when testing your configuration and looking for errors.
create a user to manage virtual mail directories
virtual mail users are those that do not exist as users on the unix system. therefore, they do not use the standard unix mailing or authentication methods, and they do not have home directories. this is how we handle things here: mail users are defined in the database created by the postfix administrator instead of existing as system users. mail will be kept in subfolders per domain and account in /var/vmail, e.g. admin@example.com will have a mail directory of /var/vmail/example.com/admin. all of these mail directories will be owned by a single user named vmail, and dovecot will use the vmail user to create and update mail files.
Note that the virtual mail directory user and folder are using the “mail” group, which allows other system users in that group to modify the content.
configure loft
dovecot will manage imap and pop3 connections, local mail directories and receive incoming mail delivered from postfix. it will also handle authentication for smtp connections as there is no point in having two separate authentication systems when dovecot can handle both cases. the configuration is distributed in a series of files in /etc/dovecot and its subfolders, and although it may seem intimidating at first, everything is presented quite logically. the first thing to do is make sure dovecot is looking for user data in the database created by the postfix admin, so you’ll want to edit these lines in /etc/dovecot/dovecot-sql.conf.ext so that it uses the mysql database created by the postfix administrator:
then change the control definitions in /etc/dovecot/conf.d/10-auth.conf so that dovecot reads the sql configuration files. while you’re there, you should also make sure plaintext authentication is disabled unless the connection is encrypted or local:
Next, you need to tell dovecot where to put the virtual users’ mail directories. that requires the following changes to /etc/dovecot/conf.d/10-mail.conf:
Tell dovecot about your purchased snake oil or certificate by editing these lines in /etc/dovecot/conf.d/10-ssl.conf. remember to include your ca certificate bundle if one was provided by the certificate issuer:
Now you need to make sure that the dovecot configuration is accessible to both dovecot and vmail users:
one final note about dovecot: it only creates a user’s mail directory when mail is first delivered to that virtual user. therefore, creating a user in postfix admin will not result in the immediate creation of a mail directory in /var/vmail, and that’s fine.
configure amavis, clamav and spamassassin
Before configuring postfix, we can also take a little detour to configure the spam and virus tools. its default settings are close to what most people will need, and tools like spamassassin automatically detect many of the optional add-on packages you may have installed. if you have specialized needs or more knowledge, you can of course spend a fair amount of time here crafting intricate rules. however, for the casual user, this is a quick and easy process. note that here we are postponing the parts related to integration with postfix, e.g. additions to the /etc/postfix/master.cf file – in the postfix section of this post.
first add amavis and clamav users to each other’s groups to allow them to collaborate:
This also requires editing the following lines in /etc/clamav/clamd.conf:
then enable amavis by editing /etc/amavis/conf.d/15-content_filter_mode. the software is disabled by default, so uncomment the @bypass… lines:
now enable spamassassin by editing these lines in /etc/default/spamassassin:
spamassassin under amavis will only review mail that is determined to arrive for local delivery. there are a couple of ways to tell amavis which emails are for local delivery, but here we will configure it to check the database configured by the postfix administrator. edit /etc/amavis/conf.d/50-user to look like this:
Next, make sure the clamav database is up to date by running freshclam. should be:
You will have to restart these processes to retrieve the new settings:
set suffix
postfix handles incoming mail via the smtp protocol, and its configuration files have been configured to allow it to integrate with the other packages we’ve installed so far. at a high level, we want postfix to deliver incoming mail to spam and virus checkers before passing it to dovecot for delivery, and to communicate with dovecot to authenticate virtual users connecting via smtp to send mail . .
You must first create a set of files that describe for postfix where to find information about users and domains. note that the “hosts” directive in these files must be exactly the same as the “bind address” in the mysql server configuration. if one side says “localhost” and the other side says “127.0.0.1”, then you may find that postfix can’t connect to mysql, weird but true. here are the necessary postfix files:
/etc/postfix/mysql_virtual_alias_domainaliases_maps.cf
/etc/postfix/mysql_virtual_alias_maps.cf
/etc/postfix/mysql_virtual_domains_maps.cf
/etc/postfix/mysql_virtual_mailbox_domainaliases_maps.cf
/etc/postfix/mysql_virtual_mailbox_maps.cf
/etc/postfix/mysql_virtual_sender_login_maps.cf
Now create the /etc/postfix/header_checks file, which will contain some directives to remove certain headers when relaying mail. This improves the privacy of sending users, for example by removing the original IP address and identifiers from the mail software. this file will be referenced in the main postfix configuration:
The following is the complete main postfix configuration file in /etc/postfix/main.cf, which contains a lot of complex choices and options about how mail is forwarded and how smtp behaves. it is well beyond the scope of this post to explain each and every best practice or configuration parameter in detail. I strongly suggest that you spend some time reading up on postfix configuration, as this is where it’s easy to fail and produce a faulty or suboptimal mail server.
Just to be clear, if you are using a purchased ssl certificate and have a bundle of ca certificates from the issuer, you will need to modify these lines in /etc/postfix/main.cf:
You should also expand /etc/postfix/master.cf, and here is the full file for clarity. this includes much of the default stuff from the package installation, such as commented out options:
Note that amavis is restricted to three processes, which should be fine for most occasional to moderate use. processes consume a lot of memory, so start small and add more only if necessary due to mail volume. see the notes in this guide for directions on how to do this.
restart everything and test the server
restarts all the processes necessary to pick up the configuration changes:
Now start testing! keep an eye on /var/log/mail.log for error messages and while logging in for pop and imap send mail to an account created on the server and send mail from the server. don’t forget to open the firewall to allow global access to the relevant ports before doing this. If you encounter problems, Google is your friend when it comes to searching for specific error messages to identify the cause of any specific problem.
aws mail restrictions and reverse dns lookup
once configured, with ip address configured and dns records configured, you will need to have a reverse dns lookup for your server and remove aws outgoing mail restrictions. it does so through the standard customer service form. this doesn’t take long, and in fact can happen earlier in the process if necessary, before the server terminates.
install and configure monit for monitoring
monit is a very useful monitoring tool that helps rescue your server from failed processes. install it via apt-get:
The following is a fairly trivial set of instructions that configures monit to watch for important server processes, but without emitting notifications or doing much more than rebooting on failure. note that the amavis configuration specifies a fairly infrequent check, as it is possible to get into a situation with amavis where it refuses connections because it is sending mail too fast and reaches the maximum number of simultaneous connections per server process (which is set to a minimum of 128 for ubuntu). having monit and then restarting amavis at that point just makes things worse, increases load and slows things down. mail will be queued and retried for any period while amavis is actually idle and waiting for monit to restart it.
create the following files in the monit configuration directory.
/etc/monit/conf.d/amavis
/etc/monit/conf.d/apache2
/etc/monit/conf.d/dovecot
/etc/monit/conf.d/mysql
/etc/monit/conf.d/postfix
/etc/monit/conf.d/spamassassin
/etc/monit/conf.d/sshd
now enable the local monit http interface by editing /etc/monit/monitrc to uncomment the following lines. this allows the use of commands such as monitor status. run monit -h to see an overview of the available options.
then restart monit to pick up the new requests:
monit offers options for notifications, a web console, restart on high load, logging activity, and many other conveniences, so you may want to add more to this very basic setup as you get more familiar with the application. An important item to note is that once the restart attempts have timed out, monit will no longer monitor that service, even after both the service and monit have restarted, until prompted. indicate. check which services are being monitored by running:
then monitor a service with:
install roundcube for webmail
roundcube is a simple php webmail package: if all you need is to simply send and receive mail through a web interface, then this is for you. Other more complex, extensible and full-featured options exist, but you pay the price for that in the time it takes to install and configure the package. roundcube is a much less onerous experience, but unfortunately the installation instructions you’ll find online on how to install roundcube are, shall we say, a bit confusing. they will largely lead you down the wrong path if you are working from a package install on ubuntu. here instead is the quick and easy way to manage things.
start by installing the necessary packages. plugin packs aren’t essential, but it doesn’t hurt to check them to see what’s available:
In the process of installing the package, you will be asked if the installer should configure the database. answer yes, then choose mysql as the database type. you will be prompted for mysql root user password, so enter it. you will then be prompted to enter and confirm a password for a new roundcube database user that will be created for you. The same comments about passwords apply here as for the ones you created earlier for the root and mail user.
In theory, the php7.0-intl and php7.0-zip modules should be enabled by default on installation, but I had some trouble getting php and apache to realize that fact. try enabling them, and if all else fails, restart the server, which is what finally worked for me:
either way, restart apache to pick up the changes:
edit the following lines in /etc/roundcube/config.inc.php to tell roundcube that the mail server applications are running on the same machine:
since /etc/roundcube/config.inc.php overrides /etc/roundcube/defaults.inc.php and contains only a small amount of the general properties, you will need to add these lines to /etc/roundcube/config.inc .php to tell roundcube to (a) redirect insecure http connections to https and (b) use the database for caching:
make sure to update the following config option in /etc/roundcube/config.inc.php to a value unique to this installation:
At the time of this writing, there are blocking issues with some of the plugins bundled with the roundcube core. can be fixed by repairing broken symlinks with the following commands:
At this point, roundcube is now installed and minimally configured, but not accessible from the webroot server. roundcube’s webroot containing php files and various symlinks is located in /var/lib/roundcube, and the next step is to make it available to visitors. this is easily achieved by creating a symlink in the web root:
now redirect the default landing page for visitors to roundcube, which first requires removing the default index page:
then expand /var/www/html/.htaccess to include a rule to only redirect the landing page to roundcube. being so selective leaves open the option of adding other files and subdirectories in /var/www/html for whatever you want to use them for, and retains access to the postfix manager.
You can now test roundcube by visiting http://mail.example.com and logging in as user.
options to help ensure deliverability
If you want a quiet life without worrying about whether your mail will reach its destination, you should take a little extra time to set up spf and dkim for your mail server. these modifications go a long way to ensuring that you will not have problems triggering false positives from spam filters. It is becoming more and more difficult to guarantee that your mail reaches its recipients. Set up a cloud mail server that uses an IP address that was used by spammers at some point in the past, or engage in a serious discussion about topics that see a lot of spam, and you can say goodbye to the certainty of mail delivery. to addresses at gmail or other similar email providers. These entities maintain their own arcane anti-spam infrastructures, inscrutable and distinct from the open world of IP address blacklists. Solving problems or just getting the attention of anyone who can help is essentially impossible if you’re not running a big company.
so everyone building their own mail server needs to configure the two simple frameworks email providers pay attention to when it comes to the decision tree for their anti-spam automation: sender policy framework ( spf) and mail identified with domain keys (dkim ).
configure sender policy framework (spf)
spf only requires that you add a txt record to your dns zone for the domain. how that happens depends on the tools provided by your domain registrar, or the tools you configure yourself in case you manage your own nameservers. If you use a registrar’s web interface to make DNS changes, you may or may not have the option to enter a subdomain for registration. if you do, leave that field blank.
This generic spf txt record authorizes mail originating from mail servers for your domain that are identified by mx records and all other servers associated with your domain that have records:
Note that double quotes are a required part of the spf txt record. Much more complicated records than this are possible, as described in the spf documentation. you can see some of these more complex examples in the wild using the dig command. for example:
server configuration for mail identified with domain keys (dkim)
configuring dkim is a bit more complicated than configuring spf. first install the necessary packages:
add the following to /etc/opendkim.conf:
add the following to /etc/default/opendkim:
add a suitable dkim configuration to /etc/postfix/main.cf:
you must add no_milters to the receive_override_options line in /etc/postfix/master.cf. this prevents multiple signatures from being placed on the same outgoing mail item. that line becomes the following:
You can now generate a private key to sign outgoing mail. Note that in the following command, dkim is the value given to the selector in /etc/opendkim.conf. this can be any simple string, as long as you are consistent in replacing dkim with the desired value throughout this recipe. run the following command to generate the key and associated materials as two files, dkim.private and dkim.txt. the former is the rsa private key, while the latter contains the entry that you will need to put in your dns records.
move the key to its place and grant the proper permissions, but don’t forget to take a copy and keep that copy in a safe place:
you will need to restart the postfix and opendkim services to recover the configuration changes so that outgoing mail is signed with dkim:
dns configuration for mail identified with domain keys (dkim)
next is the dns registry settings. how you do it depends entirely on how you manage dns or how it is managed for you – everyone’s tools are different. Please note that some registrars do not allow you to create raw txt records with specific subdomains, which will prevent you from creating dkim txt records. if this is the case then you will need to transfer your domain to a real registrar that will let you play with all the toys.
the dkim.txt file contains the following content, the complete txt record to be created. has the subdomain dkim._domainkey and a long set of value-encoded content. again dkim is the value given to the selector in /etc/opendkim.conf.
when adding the dns record you must omit k=rsa; t=y; portion of value. the first element refers to the format of the key and the default value is rsa. second, it indicates that this is a test entry and should not be included. therefore, the value to add looks like this:
It is useful to see examples in the wild for comparison purposes, so you can see how you should enter the value in your logs. you can use dkim key checker or other tools like dig. note that dkim._domainkey is the subdomain in the following command:
monitor the opendkim service
add a configuration file /etc/monit/conf.d/opendkim:
then restart monit:
share a dkim key for multiple domains
if you are serving multiple domains from the same mail server, then the content of /etc/opendkim.conf should be:
This will work unless you’re running a mailing list or similar, where outgoing mail has headers containing addresses at domains other than the list’s domain. in that case, you can look up a helpful server failure question and answer for more complex setups that can support that scenario.
testing spf and dkim settings
The only safe test is to send mail from the server and inspect it. a decent testing service is the mail tester, which will report on the validity of spf and dkim additions to mail headers. remember to give dns changes a chance to propagate before using it.
notes on postgrey
You will find that postgrey has its own idiosyncratic notion of what the default setting should be and how it should work. there are whitelist configuration files for clients and recipients in /etc/postgrey/whitelist_clients and /etc/postgrey/whitelist_recipients respectively, but they are not actually used by default. if you want to use them, you have to copy them to /etc/postfix like this:
or alternatively edit /etc/default/postgrey:
notes on the multi-domain service
you can create multiple domains in postfix admin if you wish, in the domains list -> new domain additional domains added in postfix admin can be associated to existing domains in virtual list -> add an alias domain, so address@example1.com always forwards to address@example2.com, or they can be presented as separate domains with their own mailboxes, aliases, etc.
Depending on your use case, you may also want to adjust some of the .htaccess rules to allow users to access the site at mail.example1.com, mail.example2.com, etc., such as expanding the redirect to ssl to recognize all domains used.
roundcube should work for multiple domains, but it requires you to create multiple configuration files. fortunately the instructions are clear.
notes on quota management
If you’ve been following closely, you’ll notice that so far nothing has been said on the subject of user disk space quotas. was not an important goal for the work that prompted the creation of these instructions. as it is, the fields required for quota management exist in the mysql database but are not used, since (a) the quota module is not enabled by default in dovecot, and (b) the admin postfix is not configured to use quotas by default.
so if you want to enable disk quotas you must first modify the postfix admin quota setting in /var/www/html/postfixadmin/config.inc.php by adding the following to /var/www/html /postfixadmin/config.local.php:
Next, you’ll want to enable and configure the quota and imap_quota modules in dovecot. the first one manages the quotas while the second one allows to inform about the quotas through imap. you’ll want to refer to the following documentation for instructions on how to do this:
These configuration changes will be made to 10-mail.conf and 90-quota.conf in the /etc/dovecot/conf.d directory.
bypassing spam and virus checks for local mail
If your business is sending newsletters or frequent local software updates where you completely control the content of those emails, then you probably don’t want to run spam and virus checks for those items. it’s a wasteful use of server processing cycles, and running a newsletter can break the server if you’re causing it to process the full range of checks on each and every one of those mails.
To have amavisd-new bypass checks for mail originating from a known set of ip addresses (for example, locally, from a web application on another server, etc.), edit /etc/amavis/conf.d /50-user to add these lines:
replace 111.111.111.111/32 with whatever set of ip address ranges you want amavisd-new checks to bypass. all mail arriving from those sources will fall into mynets for amavisd-new and thus bypass verification. If omitting the ip address doesn’t suit your needs, you can find ways to skip checks for some users, targets, or sources in a helpful but dated guide to integrating amavisd-new and postfix.
some final notes on security
You will notice that there are a fair number of configuration files containing database passwords for mail and webmail data on this server, and that includes php files found in the web root. this is not really the main security concern – mail users are virtual and only the server administrator needs to log in as system user. in aws, the default setting is for ssh login to use keys instead of passwords, and only the ubuntu user has a key setting to allow login. You can also easily block the ssh port for selected ip addresses through the security group applied to the server. additionally, you can set .htaccess directives to ensure that no web visitor can directly view the config files and thus they are only used as included, which covers the rare case where some error causes apache serve the php files as plain text. access to mysql is only from localhost, in any case.
Overall, the lowest bar from a traditional security perspective is probably that the mail server built here runs a couple of complicated php web applications with database access. A serious violation would involve a way to load and execute an arbitrary php script or shell command with the permissions of the www-data user, or other xss attacks that allow session hijacking of administrators. Either way, or just getting into the databases, the webroot compromise is the compromise of all important server functions. Major PHP webmail applications have exhibited multiple serious vulnerabilities over the years, but at some point you have to choose your software. In general, given the choice, I prefer to go with the output of established development communities whose members have a proven track record of vulnerabilities being found and fixed, and where there are a lot of eyes on the code base.
These are all good reasons to set up your webmail on a different server than the one running postfix and dovecot, something to keep in mind.
of course being on aws, or indeed any type of hosting readily available in the us. uu. in which the server is not in your living room, it means that the us government. uu. you have free access to your data anytime you feel particularly up to the task. , and you may never know a copy was taken. One of the next welcome evolutions in virtual hosting services will be some form of turnkey encrypted server operations, so you can have the convenience of an AWS-style service but without the transparency that today’s panoptic offers. .
Also, apparently all email traffic between mail servers is being logged by various government agencies. unfortunately the current state of smtp in general is that many or most mail servers do not implement the ability to pass email over an encrypted connection: so while it is easy to configure and apply encryption to pop, imap, and webmail connections between users and the mail server, email traffic between mail servers is usually plain text. forcing your server to only use encrypted connections to other servers will mean that a large fraction of your email traffic will be rejected in both directions. therefore, the setting provided for postfix in this post is for optional encryption: sent and received emails will be encrypted if the mail server at the other end of the connection can support it.