Making a Mailserver (Part 4) - Credibility is Critical

This is an instalment in my series on setting up a Linux based mailserver. See these posts:

• Making a Mailserver (Part 1) - What's in a Name
• Making a Mailserver (Part 2) - My Personal Daemons: Exim and Dovecot
• Making a Mailserver (Part 3) - Let's Encrypt Webmail
• Making a Mailserver (Part 4) - Credibility is Critical
• Making a Mailserver (Part 5) - Wonderful Spam
• Making a Mailserver (Part 6) - Server Migration & Backup

Your mailserver has no reputation on the Internet. Even if it did, years of good reputation can be wiped away in a few 'open relay' minutes.

It's time to setup SPF and DKIM with bind and exim4.

DMARC

To ensure to the rest of the Internet that your server right at this moment is one of the good guys, set up everything you can within the DMARC framework.

The DMARC (Domain-based Message Authentication, Reporting & Conformance) concept is A Good Thing. The principles allow a mail server to express its validity. The DMARC methods allow sender validation through one or both of SPF and DKIM. That means, it is still possible for someone to spoof emails from your domain, but when your mailserver sends a message, SPF and DKIM validation is proof that that message at that moment is positively from your approved mail agent.

Some mail receivers will fail the DMARC validation lookup on messages and still deliver the email. However, if your mailserver starts out with a higher spam score (for whatever reason), the DMARC validation on your mailserver may be enough to mark down the spam score and get your email to its intended recipient.

In this example. we will set up:

• SPF
• DKIM

These standards try to solve the same problem (sender validity), but are often both checked, so we'll set up both. It's remarkably easy to configure them, particularly if you have unrestricted control of your DNS records.

SPF

This is dead simple to setup.

In part 1 we set up the minimum required DNS records, including the mail server (MX) record. Now we head back to bind9 to add a TXT record. Put this in the top level $ORIGIN section; i,e, where the NS records hang out.

/etc/bind/moff.tech.zone

TXT     "v=spf1 mx -all"

This record states that the SPF version is 1 and that all MX DNS records are entitled to deliver mail for moff.tech. MX is the record type, but could also include IP or IPv6 addresses. The "-all" says that anything in the list is authorised for the domain.

Visit The SPF Project website for detailed information on syntax.

In earlier times, this was an "SPF" record instead of "TXT", but "SPF" has been deprecated in favour of a "TXT" record.

DKIM

Review this debian-administration page before carrying out the steps, in order to make sense of the details. DKIM (DomainKeys Identified Mail) is easy to understand if your familiar with the concepts of PKI. If not, understanding what you're about to do next will be a steep but highly valuable learning curve.

Quoting a couple of points from the debian page mentioned above.

When a mail is sent a number of fields are hashed together, and that hash is then signed with the private key.

To validate an incoming message the receiver can see the from-address, perform the DNS-lookup necessary to find the public-key, and then repeat the hashing-process to compute the signature. If it matches then the result will be a "pass".

The intention is that only somebody who has control of the DNS for a domain can send mail from it - because all others will be missing the private key, and unable to sign the message.

We will create a private and public key so that your mailserver can put a signature, using the private key, to each email that can be verified by using the public key. The public key is retrieved with a query to your DNS server. The public key can be used to verify the signature, but cannot be used to forge your signature. That's the beauty of PKI.

In the next set of commands, we create the DKIM keys with openssl.

# sudo mkdir /etc/exim4/dkim
# cd /etc/exim4/dkim
# sudo openssl genrsa -out moff.tech.pem 1024 -outform PEM
# sudo openssl rsa -in moff.tech.pem -out moff.tech-public.pem -pubout -outform PEM

On my Debian system, I set the file permissions on the dkim directory (and files within) as so: 

drwxr-x---  2 root Debian-exim  4096 Jun  5 21:34 dkim

The Debian-exim group has permission to read the directory and files, while other (non root) users are permitted no access to these files whatsoever. This step may not be required, but it made sense to me in the context of how exim4 wants certificate file permissions to be set (see part 3).

Now tell exim4 that you want to sign messages with DKIM and where the key files are:

/etc/exim4/conf.d/main/00_my_macros

DKIM_CANON = relaxed
DKIM_SELECTOR = 20160629
DKIM_DOMAIN = ${lc:${domain:$h_from:}}
DKIM_PRIVATE_KEY=${if exists{/etc/exim4/dkim/${dkim_domain}.pem} {/etc/exim4/dkim/${dkim_domain}.pem}}

• The 20160629 is an arbitrary value, which for me indicates the date YYYYMMDD. There's nothing intrinsically important about the value here, but we reference it shortly when we create the DNS record.

• I'm using a dynamic DKIM_DOMAIN and DKIM_PRIVATE_KEY configuration because I handle email for multiple domains, This configuration avoids repetitious configuration per domain. You don't need to think about it as long as the key names match the domain you are handling email for. Exim4 will (with a small computational overhead) dynamically work out the correct key to sign each email.

Now regenerate the configuration and restart exim4 :

# update-exim4.conf 
# service exim4 restart

The update-exim4.conf is essential. If email is going out, but no dkim signing is happening, then this is quite likely because the new configuration hasn't been picked up. Only restarting exim4 is not enough.

Put the public key file into a DNS TXT record, located within the correct $origin section.

/etc/bind/moff.tech.zone

$ORIGIN moff.tech.

_domainkey      IN TXT  "t=y;o=~;r=postmaster@example.com" 20160629._domainkey     IN TXT "k=rsa; p=XXX"

• I have changed the email address to use example.com to stop bots scraping my email address from this blog post. You must use a real address.

• p=XXX is the literal public key contained in the file moff.tech-public.pem, which you generated earlier. There's no problem from a security standpoint with me repeating the string in this post (it's publicly available by definition), but it is lengthy and it is useless to anyone other than me.

Of course, if you are handling email for multiple domains, you'll want to do this for each domain's zone file.

Surprisingly, you will get a daily summary email from other domains, primarily from hotmail, google and yahoo. I believe (but I'm not not absolutely sure) that this is standard when in 'testing mode'. The t=y element of the record means (according to RFC6376):

t= Flags, represented as a colon-separated list of names plain-
   text; OPTIONAL, default is no flags set).  Unrecognized flags MUST
   be ignored.  The defined flags are as follows:

  y  This domain is testing DKIM.  Verifiers MUST NOT treat messages
     from Signers in testing mode differently from unsigned email,
     even should the signature fail to verify.  Verifiers MAY wish
     to track testing mode results to assist the Signer.

That is to say, that "y" means "testing mode" and messages don't get dropped. During initial setup or server migration this is critical. Review the emails for SPF and DKIM 'fail' results as this will tell you if something is wrong. The results may tell you what other hosts are impersonating your mailserver!

My experience is that some mailservers are badly configured (or designed) and don't handle well messages that are relayed through a mailing list. There are different ways that this can go wrong, but I have personally seen SPF lookups fail because the sending list server is not (obviously enough) in my list of MX servers. This appears to be faulty logic on the recipient's behalf, because the receiver has looked up the SPF on my domain instead of the mailing list domain. [If you want to correct or fill this point in, please use the comments section, I really want to learn some more about this.]

Once you set up the DKIM record, you'll start to receive summary messages from a few places. The xml attachment will look similar to the following and gives you an indication on who's been sending email on your behalf as well as what passed and failed.

<feedback>
 <report_metadata>
  <org_name>google.com</org_name>
  <email>noreply-dmarc-support@google.com</email>
  <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
  <report_id>121341234</report_id>
  <date_range>
   <begin>1466812800</begin>
   <end>1466899199</end>
  </date_range>
 </report_metadata>
<policy_published>
 <domain>moff.tech</domain>
 <adkim>r</adkim>
 <aspf>r</aspf>
 <p>none</p>
 <sp>none</sp>
 <pct>100</pct>
</policy_published>
 <record>
  <row>
   <source_ip>64.x.x.x</source_ip>
   <count>1</count>
   <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>pass</spf>
   </policy_evaluated>
  </row>
  <identifiers>
   <header_from>moff.tech</header_from>
  </identifiers>
  <auth_results>
   <spf>
    <domain>moff.tech</domain>
    <result>pass</result>
   </spf>
  </auth_results>
 </record>
</feedback>

In the above, you can see that for the sender 64.x.x.x DKIM failed while SPF passed. The message is probably legitimate, but DKIM has possibly been set up incorrectly [Editor's note: it was]. SPF passed so it appears that the final result was that 1 message was successful received.

Caution

The debian-administration website was at one point wrong. The page is great but used exim4 variable syntax that just did not work and was plainly wrong in the context of the wider example as they dropped "-private" from the DKIM_PRIVATE_KEY.

Further References

https://dmarc.org/overview/ 
I highly recommend this site to check your setup:
http://www.appmaildev.com/en/dkim/ 
This site does a basic check on whether your DKIM DNS is okay:
https://www.mail-tester.com/spf-dkim-check

Making a Mailserver (Part 3) - Let's Encrypt Webmail

This is an instalment in my series on setting up a Linux based mailserver. See these posts:

• Making a Mailserver (Part 1) - What's in a Name
• Making a Mailserver (Part 2) - My Personal Daemons: Exim and Dovecot
• Making a Mailserver (Part 3) - Let's Encrypt Webmail
• Making a Mailserver (Part 4) - Credibility is Critical
• Making a Mailserver (Part 5) - Wonderful Spam
• Making a Mailserver (Part 6) - Server Migration & Backup

You May Not Want Webmail, But...

Consider webmail as an optional section, Let's Encrypt as mandatory. Webmail is not something that I recommend you set up on your mailserver, but webmail is handy as a when all else fails backup. When you're travelling, you can't be sure that you can SSH to your mailserver. Protocols outside of HTTP, HTTPS and DNS are often blocked, which makes mutt not an option. When visiting friends and family, I've found mail clients can be forbidden SMTP or IMAP protocol access to locations outside of the ISP.

On the downside, setting up a web server uses valuable server resources, increases complexity and widens your security exposure.

On the security point, I use squirrelmail and honestly I don't know that it's a very good option. I think squirrelmail is easy to set up and lightweight to run, but development appears to have stopped, which means that security updates won't be arriving. On the other hand, from the remote attacker standpoint if an attacker doesn't already have the username and password of a mail user, then they only have the squirrelmail login page to hack away at. Well hackers are inventive, there should be other avenues into it than just that page. An attacker could craft a malicious message, targeted to exploit squirrelmail, that a user might open via squirrelmail. It's an acceptable risk to me, for now.

If you're not interested in setting up a webmail front-end, what this section will additionally do is provide an easier path to set up Apache for the generation of Let's Encrypt certificates to use with your IMAP and SMTP server daemons.

Apache

Apache will host the squirrelmail install or, at the very least, host the method by which you can easily generate a certificate for your mailserver via letsencrypt. If only required for the latter option, Apache need only be enabled for the duration of the certificate generation and subsequent renewals, saving server resources and reducing your security exposure.

On a default install of Apache there is probably not a lot required to be configured. Apache comes with a default site for both SSL and HTTP. In the /etc/apache2/sites-available/ one should see a "default" and "default-ssl" file.

Check that mod_ssl is enabled:

$ sudo a2enmod mod_ssl

 Check whether the "default-ssl" and "default" sites are enabled:

$ ls -la /etc/apache2/sites-enabled/
-rw-r--r-- 1 root root   692 Dec  3  2015 default -> ../sites-available/default
-rw-r--r-- 1 root root  7251 Dec  3  2015 default-ssl -> ../sites-available/default-ssl

You don't need the default site, because you shouldn't be serving up other pages for sport, only webmail over SSL (HTTPS). 

$ sudo a2ensite default-ssl
$ sudo a2dissite default

Ideally you would copy those sites and customise your own sites based on those files, for example: 

$ ls -la /etc/apache2/sites-enabled/
lrwxrwxrwx 1 root root   47 Jun  1 16:45 ssl-mail.moff.tech.conf -> ../sites-available/ssl-mail.moff.tech.conf

Notice that when you use the a2ensite / a2dissite a symbolic link is created from sites-enabled to sites-available.

We'll discuss now the customisation of the ssl site file, including the stanza for squirrelmail. Please bear in mind the following:

• This is an abridged version to highlight the things that need to be changed.
• I'm not promising you the most secure or optimised configuration. 
• It's really up to you to understand and research the settings here via Apache's useful, although sometimes dense, documentation. For security, you might want to start here.

<VirtualHost *:443>
        ServerName mail.moff.tech:443
        DocumentRoot "/usr/share/squirrelmail"
        ServerAdmin me@example.com
        SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
        SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
</VirtualHost>

I'm using example.com because I don't want spam robots harvesting my email address from this blog post.

We've altered the document root to be the squirrelmail install directory. If squirrelmail isn't installed yet, then this is going to cause Apache to complain when reading the config. At the very least, install squirrelmail (we'll customise it later) and set the document root accordingly. Note that this should not be set to the /etc/squirrelmail directory.

If you don't want to use squirrelmail, just leave DocumentRoot as default.

We'll revisit the SSL certs after sorting out letsencrypt. For now, leave them at the defaults (self signed certs), whatever they be called.

Don't move on to the letsencrypt stage until you can get Apache to start your ssl site successfully and have checked that your mail web address resolves and serves some web page - albeit with a self signed cert warning from your browser.

Let's Encrypt and Apache Integration

I don't need to go into a lot of detail here for setting up a Let's Encrypt certificate. Let's Encrypt have issued a million certificates and there's about as many user howtos and blogs to step you through. It works remarkably well as long as you do everything to the letter and have a simple Apache ssl site setup, like ours.

In truth you can use the letsencrypt standalone option and skip Apache altogether.

I've used the letsencrypt.sh client and it works well enough. I see that Let's Encrypt are now pushing something called certbot. I guess that's an experiment for me to do another time (and blog post).

Update: As of January, I notice that the letsencrypt-auto now presses certbot-auto. When running an update you receive "You are running with an old copy of letsencrypt-auto that does not receive updates, and is less reliable than more recent versions. We recommend upgrading to the latest certbot-auto script, or using native OS packages." However the cert is still succesfully issued.

Once you've stepped through the setup, check the location of the cert files. This is probably going to vary depending on the client you used to get the cert issued.

root@mail:/etc/apache2/ssl# ls -la /etc/letsencrypt/live/mail.moff.tech/
total 8
drwxr-xr-x 2 root root 4096 Jun 11 10:14 .
drwx------ 3 root root 4096 Jun 11 10:14 ..
lrwxrwxrwx 1 root root   43 Jun 11 10:14 cert.pem -> ../../archive/mail.moff.tech/cert1.pem
lrwxrwxrwx 1 root root   44 Jun 11 10:14 chain.pem -> ../../archive/mail.moff.tech/chain1.pem
lrwxrwxrwx 1 root root   48 Jun 11 10:14 fullchain.pem -> ../../archive/mail.moff.tech/fullchain1.pem
lrwxrwxrwx 1 root root   46 Jun 11 10:14 privkey.pem -> ../../archive/mail.moff.tech/privkey1.pem

That confirmed, you can head back to the Apache ssl site and verify the certificates. Where you had this:

SSLCertificateFile    /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key

You should now have (or add) this:

SSLCertificateFile      /etc/letsencrypt/live/mail.moff.tech/cert.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/mail.moff.tech/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/mail.moff.tech/chain.pem

Reload (you don't need to restart) Apache and check for errors at startup. Now you can disable Apache if you don't want to set up webmail.

The certificate you've been issued only lives for a few months. Consider a crontatb entry to renew the certificate. For example, this renews every three months (months 3, 6, 9, 12) on the 8th day:

1 0 29 JAN,APR,JUL,OCT * /root/letsencrypt/letsencrypt-auto renew

I have a script (tested and verified with crontab) to handle the renewal process because, as we will see shortly, when the certificates are required for multiple jobs the file permissions don't suit every daemon. Check out letsencrypt-handle-certs.sh on my gitlab repository.

Finally, when Apache is enabled, verify your SSL/TLS strength via SSL Labs.
 

Squirrelmail

The default install of sqm offers an apache.conf but I recommend that you ignore it. It doesn't show you the HTTPS context and you don't want to expose configtest.php anywhere.

There is a lovely script to configure Squirrelmail just as you want it:

$ sudo squirrelmail-configure

Some of the config points are these:

$imapServerAddress      = 'mail.moff.tech';
$imapPort               = 993;
$useSendmail            = false;
$smtpServerAddress      = 'mail.moff.tech';
$smtpPort               = 25;

Troubleshooting squirrelmail 

When sending an email via Squirrelmail, it may fail with a 550 message about relay not being permitted. This is because Squirrelmail didn't pass AUTH so the server doesn't trust the client and won't relay for it. The quick resolution is to add the server IP into the list of "Machines to relay mail for" in the Exim config as I mentioned in part 2.

I found that Squirrelmail will try an AUTH before Exim offers it. In other words, if you set this in /etc/squirrelmail/config.php:

$smtp_auth_mech = 'login';

Then the result may be a new problem:

Bad sequence of commands
503 AUTH command used when not advertised

Exim wants to do AUTH after TLS but Squirrelmail tries to do AUTH before that. The workaround for this is to set $smtp_auth_mech = 'none'; and make sure that the IP of the server is set as a host to be a smarthost for. This setup of Squirrelmail doesn't use TLS to connect to Exim, I can't make that work with AUTH. I ended up with a message about being unable to open the TCP stream and this in the syslog:

SMTP protocol synchronization error (input sent without waiting for greeting): rejected connection from H=mail.moff.tech [64.x.x.x] input="\026\003\001"

Since packets from Squirrelmail never leave the box, from a security standpoint there's little to gain with a TLS connection - unless you distrust your server processes or users. Some web searching might reveal a solution to setting up Squirrelmail with TLS and AUTH. If you find one, let me know!


Squirrelmail will use the system user credentials by default. If you try to login as root, then squirrelmail will fail to get in. You'll see something like this in the syslog:

Jun 22 22:57:07 mail dovecot: imap-login: Login: user=<root>, method=PLAIN, rip=x.x.x.x, lip=y.y.y.y, mpid=25745, TLS, session=<N5s1LuQ1HQBAFlV3>
Jun 22 22:57:07 mail dovecot: imap: Error: user root: Invalid settings in userdb: userdb returned 0 as uid
Jun 22 22:57:07 mail dovecot: imap: Error: Invalid user settings. Refer to server log for more information.

Setting the servername to match the one on the certificate will avoid errors such as this:

Jun 11 12:06:05 mail dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=::1, lip=::1, TLS, session=<Tvayzf00ZQAAAAAAAAAAAAAAAAAAAAAB>

Above, the certificate servername validation was probably failing. You can't use the loopback address or you'll get that kind of error.

Additionally, an error log message like this one:

Jun 11 11:55:55 mail dovecot: imap-login: Disconnected (no auth attempts in 0 secs): user=<>, rip=x.x.x.x, lip=y.y.y.y, TLS: SSL_read() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session=<qutPqf00mABSh18U>

Will likely happen if the CA is unknown. You might see this if you've copied a self signed cert from another server without copying the "Self CA" as well. Rather than faff about sorting out a self signed cert, use Let's Encrypt.

Dovecot Certificate Integration

To splice the new certs into the Dovecot configuration, you might get away with simply calling the Let's Encrypt cert files where they stand.

Edit /etc/dovecot/dovecot.conf:

ssl_cert = </etc/letsencrypt/live/mail.moff.tech/fullchain.pem
ssl_key = </etc/letsencrypt/live/mail.moff.tech/privkey.pem

Then reload and watch the logs for errors.

After my first attempt at adding the Let's Encrypt cert, Thunderbird reported that my cert was still essentially self signed. I hadn't used the "full chain" file so apparently that meant Thunderbird wasn't too sure who the root CA was. This is possibly because Thunderbird didn't have the intermediate CA certs stored. Mozilla applications will apparently tuck a received Intermediary CA cert away for later reference. Using the full chain file allows Thunderbird to iterate the chain of authority.

That's also why you set the chain file in the Apache config.

Exim4 Certificate Integration

The exim4 config file states categorically:

# Full paths to Certificate and Private Key. The Private Key file
# must be kept 'secret' and should be owned by root.Debian-exim mode
# 640 (-rw-r-----). exim-gencert takes care of these prerequisites.

As it's a bad idea to tinker with the cert file permissions and owner/group. Copy them into the /etc/exim4/ directory and set the permissions accordingly:

# ls -l /etc/exim4/ | grep 'pem'
-rw-r----- 1 root Debian-exim  3456 Jun 12 22:01 fullchain.pem
-rw-r----- 1 root Debian-exim  1704 Jun 12 22:01 privkey.pem

If you're copying over the old files, then you don't need to change the exim4 default configuration. If you're editing the exim config, here's how:

/etc/exim4/conf.d/main/03_exim4-config_tlsoptions:

.ifndef MAIN_TLS_CERTIFICATE
#MAIN_TLS_CERTIFICATE = CONFDIR/exim.crt
MAIN_TLS_CERTIFICATE = CONFDIR/fullchain.pem

.ifndef MAIN_TLS_PRIVATEKEY
#MAIN_TLS_PRIVATEKEY = CONFDIR/exim.key
MAIN_TLS_PRIVATEKEY = CONFDIR/privkey.pem

Notice that we're using fullchain again.

I'm handling these steps in a cert renewal script, but at the time of writing I'm not ready to publish that script due to it having had very little testing.

After updating the cert file location, reload exim.

# service exim4   reload

Watch /var/log/syslog, /var/log/exim4/mainlog and /var/log/exim4/rejectlog for unusual messages.

Making a Mailserver (Part 2) - My Personal Daemons: Exim and Dovecot

This is an instalment in my series on setting up a Linux based mailserver. See these posts:

• Making a Mailserver (Part 1) - What's in a Name
• Making a Mailserver (Part 2) - My Personal Daemons: Exim and Dovecot
• Making a Mailserver (Part 3) - Let's Encrypt Webmail
• Making a Mailserver (Part 4) - Credibility is Critical
• Making a Mailserver (Part 5) - Wonderful Spam
• Making a Mailserver (Part 6) - Server Migration & Backup

The Boring Preamble

In this post, we set up exim4 as an mail receiver (and personal email relay) and dovecot as your secure IMAP service. Why use exim4 and dovecot? Because there's safety in numbers; these are tremendously popular daemons, have comprehensible config structures and are well documented. That documentation extends to a lot of user sites, like this blog, where people post their own experiences and suggestions.

Security is the primary concern. Dovecot provides secure IMAP, but I needed exim to allow me to relay my mail. If you blindly turn on mail relay then soon enough most of the population of Eastern Europe and various other countries will be using your server as a spam hub and malware pivot-point.

This image is deliberately vague, but it is definitely of mailboxes

exim4

A mail relay is a server that accepts mail for destinations that are not delivered locally to that server. A relay assumes the responsibility of sending that email on to its intended destination. Relay is what I needed, but I was reluctant to share my server bandwidth with spammers. It is possible to configure exim4 to be a mail relay only on behalf of authorised hosts and users.

But first, you need to get exim4 off the ground with the basic config. The exim4 setup wizard is really great. On debian you can invoke this with

dpkg-reconfigure exim4-config

The magic of this wizard is that you can run it over and over while you try to get the settings right. The wizard won't overwrite customisations you've made in the other config files, unless those customisations pertain specifically to questions in the wizard.

Setup Wizard Explanation

General type of mail configuration:

Select: internet site; mail is sent and received directly using SMTP

System mail name:

Input: example.com
Do not put something like mail.example.com or hostname.example.com!

IP-addresses to listen on for incoming SMTP connections:

Input nothing.
This is an Internet facing mail server, you can't reduce your risk here.

Other destinations for which mail is accepted:

Input: anotherexample.com; yetanotherexample.com
Any other domains that you plan to receive mail for is added here. At this stage you probably want to leave this empty.

Domains to relay mail for:

It's really a good idea to leave this blank. If you wanted to accept and deliver mail for another domain and not deliver locally, then here is where you configure that. This may be like playing with fire if you are not in control of the domains that you list here. Don't confuse it with the "other destinations" question earlier, which is about local delivery.

Machines to relay mail for:

Input any host IP addresses that you control, for which you want to handle mail from. This is incredibly useful. You have several servers out on the Internet and you want them to be able to send email to the rest of the world, you can tell those servers to use this server as their "smarthost" mail relay. If you are going to set up Squirrelmail per my instructions then you must enter your own server's IP here. Squirrelmail in this setup will connect to Exim using the server's IP as its source.

Instead of trying to configure several servers with tight mail rules and dmarc policies, you need only configure this server and have your other servers relay their outgoing email here.

Keep number of DNS-queries minimal (Dial-on-Demand)?

Nobody cares, select "No".

Delivery method for local mail:

You probably want to select: "mbox format in /var/mail/"

Split configuration into small files?

Select "Yes". You end up with a mess of files, but in the long run I think it's better. The rest of this guide is based on this setting being enabled..

That's the last question. Now the basic framework of your mailserver is setup. The tricky secure lockdown is next.

With exim4, you can enable relay for the specific case where the sender is authenticated. In other words, if I can prove to my server that I am an authenticated person, then my server will relay my emails. When I connect to my mailserver to send email, I go through a username/password challenge.

You don't want to do the authentication over plain text, so encrypting the traffic is key to reducing the likelihood that someone will crack your username and password. That's what the STARTTLS method is for.

I'm not going into particular detail as to each setting, these you can look up for yourself in the exim4 documentation. Here's the step-by-step configuration. 

Adding the Security

Edit /etc/exim4/update-exim4.conf.conf and check that you can see this (if you can't, then you ignored my recommendation earlier and I can't help you anymore):

dc_use_split_config='true'

Now add these lines to the end of the file:

host_auth_accept_relay=*
auth_over_tls_hosts=*
auth_always_advertise=true

 Create a file called /etc/exim4/conf.d/main/00_my_macros and add this:

MAIN_TLS_ENABLE = true
AUTH_PLAINTEXT=yes
AUTH_CRAM_MD5=yes

You'll be back in this file later if you set up DKIM via my setup guide.

Now edit /etc/exim4/conf.d/auth/30_exim4-config_examples and uncomment/setup this section:

plain_server:
 driver = plaintext
 public_name = PLAIN
 server_condition = "${if crypteq{$auth3}{${extract{1}{:}{${lookup{$auth2}lsearch{CONFDIR/passwd}{$value}{*:*}}}}}{1}{0}}"
 server_set_id = $auth2
 server_prompts = :
 .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS
 server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}}
 .endif

Because you've made changes to the split config, run the config updater and then reload: 

update-exim4.conf

service exim4 reload

At the time of writing, I am not sure whether both steps are really required.

Fake Certificate

In later posts, you'll find out how to attach a letsencrypt certificate (a real certificate) to apache, exim and dovecot. For now though, let's just get something working.

Generate your own certificate for exim to use in STARTTLS (debian example):

 /usr/share/doc/exim4-base/examples/exim-gencert --force

You'll need to answer some questions, you can't get them wrong. It's an untrusted (self signed) certificate. We'll get a real certificate sorted out later, via letsencrypt. One thing at a time.

The certs will hopefully be dumped into the /etc/exim4/ as exim.crt and exim.key. Debian-exim will need to be able to read this and you can't have an all readable flag

chmod 640 /etc/exim4/exim.*

chown root.Debian-exim /etc/exim4/exim.*

ls -l /etc/exim4/
...
-rw-r----- 1 root Debian-exim   790 Sep 16 14:12 exim.crt
-rw-r----- 1 root Debian-exim   891 Sep 16 14:12 exim.key

Troubleshooting exim4

There is an excellent debug mode that you can run exim in. If you have problems, stop exim and start it in debug mode:

/etc/init.d/exim4 stop  

exim -bd -d -oX 25

Of course, when you want to start exim normally again, use the "start" option instead of "stop".

Tail the exim 'mainlog' and 'rejectlog' logfiles in /var/log/exim4 as you test email delivery to your server.

http://bradthemad.org/tech/notes/exim_cheatsheet.php

Dovecot

Configuring dovecot is relatively straightforward and doesn't need a lot of explaining. The dovecot help pages are very good. Don't randomly google problems, check those pages first.

I don't have any notes from the first time I set up dovecot as it is getting on for a decade ago and the config evolved over time. Over all these years, there appear to have been no configuration syntax changes that have affected me, until I jumped from Debian 6 to Debian 8 (Jessie).

When I did server migrations in the past, I lazily copied the old dovecot config files into the new /etc/dovecot directory and miraculously dovecot still started. The same was true when I migrated to Debian 8.5. However, I was confronted by these messages in /var/log/syslog:

doveconf: Warning: NOTE: You can get a new clean config file with: doveconf -n > dovecot-new.conf
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:25: 'imaps' protocol can no longer be specified (use protocols=imap). to disable non-ssl imap, use service imap-login { inet_listener imap { port=0 } }
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:100: ssl_cert_file has been replaced by ssl_cert = <file
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:101: ssl_key_file has been replaced by ssl_key = <file
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:718: protocol managesieve {} has been replaced by protocol sieve { }
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:890: add auth_ prefix to all settings inside auth {} and remove the auth {} section completely
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:928: passdb pam {} has been replaced by passdb { driver=pam }
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:1041: userdb passwd {} has been replaced by userdb { driver=passwd }
doveconf: Warning: Obsolete setting in /etc/dovecot/dovecot.conf:1103: auth_user has been replaced by service auth { user }

I ran "doveconf -n > dovecot-new.conf" as suggested and the configuration was boiled down to this simple setup:

log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_privileged_group = mail
passdb {
  driver = pam
}
protocols = imap
service auth {
  user = root
}
service imap-login {
  inet_listener imap {
    port = 0
  }
}
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem
userdb {
  driver = passwd
}
#protocol imap {
#  mail_max_userip_connections = 20
#}
#protocol pop3 {
#  pop3_uidl_format = %08Xu%08Xv
#}

Notes on the above:

• We'll setup letsencrypt certs later.
• You should have certs generated automatically, if you want to learn more about handling them with correct file permissions and so on, refer to the dovecot wiki.
• I commented out the last lines by hand.

A default install of dovecot sees many files placed inside the dovecot directory. Out of interest, I removed all of them except for the earlier generated dovecot-new.conf, which I renamed to dovecot.conf. Dovecot still started and remote connections to the server worked. Using "nmap localhost" I could verify that the listening ports were just the same. Therefore, I could verify that the other files were technically unnecessary for the pupose of this setup. However, to ensure your ease for future customisation, you'll want to leave those default files there.

In my version of the config, I am not using an include statement in dovecot.conf, so the conf.d files are not read. The dovecot documentation is really good, see http://wiki.dovecot.org/BasicConfiguration:

The default configuration starts from dovecot.conf, which contains an !include conf.d/*.conf statement to read the rest of the configuration. This split of configuration files isn't a requirement to use, and it doesn't really matter which .conf file you add any particular setting, just as long as it isn't overridden in another file. You can verify with doveconf -n that everything looks as you intended.

If you use systemd, you may encounter these messages:

# service dovecot start
Jun 14 22:09:56 mail dovecot[20409]: Error: systemd listens on port 143, but it's not configured in Dovecot. Closing.
Jun 14 22:09:56 mail dovecot: master: Error: systemd listens on port 143, but it's not configured in Dovecot. Closing.
Jun 14 22:09:56 mail dovecot[20409]: Error: systemd listens on port 143, but it's not configured in Dovecot. Closing.
Jun 14 22:09:56 mail dovecot: master: Error: systemd listens on port 143, but it's not configured in Dovecot. Closing.
Jun 14 22:09:56 mail dovecot: master: Dovecot v2.2.13 starting up for imap (core dumps disabled)

The messages are not actually something to worry about. Suggestions around the Internet say that they can be stopped as so:

# systemctl disable dovecot.socket
Removed symlink /etc/systemd/system/sockets.target.wants/dovecot.socket.

I'm not sure whether that works. You might want to do some googling to understand more about systemd. For now, it's not important.

Troubleshooting Dovecot

Use "tail -vf /var/log/syslog" to see dovecot reporting IMAP authentication and connections.

There are further troubleshooting notes in the Webmail post (part 3) of this series.

Once again, the dovecot docs are really good!
http://wiki.dovecot.org/RunningDovecot
http://wiki.dovecot.org/FrontPage#Troubleshooting

Making a Mailserver (Part 1) - What's in a Name

This is an instalment in my series on setting up a Linux based mailserver. See these posts:

• Making a Mailserver (Part 1) - What's in a Name
• Making a Mailserver (Part 2) - My Personal Daemons: Exim and Dovecot
• Making a Mailserver (Part 3) - Let's Encrypt Webmail
• Making a Mailserver (Part 4) - Credibility is Critical
• Making a Mailserver (Part 5) - Wonderful Spam
• Making a Mailserver (Part 6) - Server Migration & Backup

You might want to start with this cautionary note, which gives you a quick overview of what's in front of you.

Some areas of what I'm writing about are more detailed than others. I'm trying to guide you into making the right decisions. I'm more verbose in areas where it's particularly tricky to understand or find the right information, but generally I expect you to find the right way of configuring  your own system.

I start with the assumption that you have your VPS or hosting machine sorted out. You should have SSH access to it and a way to console to it should you manage to hose the networking or lock yourself out.

Also, do not use your mailserver for anything else other than mail and if necessary DNS. For example, don't serve your fast and loose PHP pages on this machine. Your mailserver will become a silent but crucial part of your day. Don't expose the machine to unnecessary risk; limit services to those that are absolutely necessary.

Notes about your Server

I strongly urge you to do the following things before you go any further.

1. Set up a user other than "root" and make sure you have a damn strong user password.

Remove root SSH access (/etc/ssh/sshd_config):

PermitRootLogin no

2. Set up key based authentication over SSH. Disable password logins over SSH if you're brave.

3. Set up "denyhosts" or its heir apparent "fail2ban", to block hosts that are bruteforcing your SSH. Brute force attacks happen all day every day.

4. Install ntp and check that the time is synchronised.

5. Configure the right timezone (tzselect). After that, restart syslog and cron.

6. Install and configure iptables to accept port 22 and 53 on TCP and UDP and block everything else. This is not always necessary. For example. if you're using AWS you should customise a security policy and apply it to the Instance.

7. Reboot your machine to make sure that the system comes back up running the daemons you require. I prefer to use sysv-rc-conf to control the daemons that start at boot time. Disable as much as you dare.

DNS

Here's what we're about to do:

1. Register the domain name.
2. Update the glue records.and/or point to other nameservers outside your domain.
3. Set up master and slave DNS server relationship.
4. Set up a zone file on the master.
5. Verify the MX record.

A Record of Sniffing Glue

Good registrars offer complimentary DNS services, which is nice, but I've never tried that. I've always done my own DNS hosting. The rest of this chapter assumes that you want to 'roll your own' DNS.

Once you've registered your domain with a reputable registrar, get the glue records sorted out. You want the glue records to point to your master and slave DNS servers.

The glue records tell the top level domain (TLD) root servers where your domain DNS servers live on the Internet.

You can verify that the glue records are active by finding your TLD servers (the registry itself) and querying them, in the following example, my TLD is "tech":

# dig tech

;; ANSWER SECTION:
tech.                   2753    IN      NS      a.nic.tech.
tech.                   2753    IN      NS      b.nic.tech.
tech.                   2753    IN      NS      c.nic.tech.
tech.                   2753    IN      NS      d.nic.tech.
 

# dig NS @a.nic.tech moff.tech

;; ADDITIONAL SECTION:
ns1.moff.tech.     86400   IN      A       54.194.x.x
ns2.moff.tech.     86400   IN      A       64.22.x.x

 The "additional section" is the critical part.

You need not set up glue records if your nameservers are outside your domain name. In which case, you only need to add the DNS server names via your registrar. That's not actually a glue record but the result is the same as long as the nameservers are reachable!

I've seen a registry requirement in the past to have a minimum of two nameservers. If you strike this and don't have a second nameserver, you can input any junk for the second nameserver and it is highly unlikely to be validated. That is, unless you live in Germany, where you can't even take control of a domain name until such time as you have two working nameservers that have both UDP and TCP open on port 53.

That was fun wasn't it? Did it seem to take forever for the glue records to get updated? One TLD for me can take between 30 to 60 minutes before the glue record changes come through.

Two Servers

My design choice was to go for two DNS servers, the mailserver itself is the master nameserver and an AWS machine is a slave. However, I configure the nameserver names so that the AWS is "ns1" and the mailserver is "ns2" in the hope that most hosts will prefer to lookup against "ns1". In truth, I have never measured the DNS lookup traffic per nameserver, I should do that...

First, tell "ns2" about the zone and that it should be a slave. The bind config is dead easy.

/etc/bind/named.conf.local

zone "moff.tech" IN {
        type slave;
        masters { 64.22.x.x; };
        notify no;
        file "/var/lib/bind/moff.tech.slave.zone";
};

The "notify no" part stops the annoying log message "refused notify from non-master" when the slave, for whatever reason, attempts to notify itself.

Zone Files

From this point we need only configure the master nameserver.

All the name to IP mappings are kept in zone files. One zone file per domain - okay, reverse DNS  makes that two files but I'm assuming you don't own your own IPv4 space. There's thousands of websites to help you with this, so I am only covering the critical bits and calling out the bind config. Remember to add the trailing dot on FQDNs.

We will revisit the bind config in later pages when we talk about mailserver reputation.

Here's a default starting point:

$ORIGIN .
$TTL 86400      ; 1 day
moff.tech          IN SOA  ns1.moff.tech. grand.moff.tech. (
                          2016060100 ; serial
                          1800       ; refresh (30 minutes)
                          900        ; retry
                          1209600    ; expire RFC1912
                          1800       ; minimum (30 minutes)
 )

Whenever you make changes to the file you need to increment the "serial" number and reload (not restart) bind. A notify is then sent to the slave server and the record transfer done.

Setup a default "A" record plus the "NS" nameservers. If you want to know what is correct for the default A record, I recommend it be the website host, if you have a website for the domain:

NS      ns1.moff.tech.
NS      ns2.moff.tech.
A       54.194.x.x

Mail record, remember this is why we're here!

MX      10 mail.moff.tech.

The "10" is a preference, if you have more than one mailserver then your primary would have a lower number to a second MX record. Two mailservers is quite tricky to setup; what's your plan to keep the mailboxes in sync? If you have two MX records, bad email delivery agents will deliver arbitrarily to either server. The moment your primary is knocked offline (even for a moment),  everyone charges off to the second mailserver.

Create a domain section and provide the real IPs of the nameservers - this should mirror the glue record!

$ORIGIN moff.tech.
ns1                     A       54.194.x.x
ns2                     A       64.22.x.x
mail                    A       64.22.x.x

That's about it.

Verification and Troubleshooting

Don't forget to verify the glue records as described above. If you didn't put in glue records but instead added nameservers from outside of your domain (you can do this and set up glue records), you should still see an authority section:

# dig @a.nic.tech moff.tech

;; AUTHORITY SECTION:
moff.tech.         3600  IN    NS      ns2.moffatt.org.nz.
moff.tech.         3600  IN    NS      ns1.moffatt.org.nz.

Your domain will remain off the Internet until you have either the "authority" or "additional" sections.

Check that your slave DNS host is able to transfer the zone (able to read the master's complete zonefile). You should see these kinds of messages (probably in /var/log/syslog):

Jun  1 09:32:08 ns1 named[5221]: client 64.22.x.x#54642: received notify for zone 'moff.tech'
Jun  1 09:32:08 ns1 named[5221]: zone moff.tech/IN: Transfer started.
Jun  1 09:32:08 ns1 named[5221]: transfer of 'moff.tech/IN' from 64.22.x.x#53: connected using 172.31.1.97#55005
Jun  1 09:32:08 ns1 named[5221]: zone moff.tech/IN: transferred serial 2016060100
Jun  1 09:32:08 ns1 named[5221]: transfer of 'moff.tech/IN' from 64.22.x.x#53: Transfer completed: 1 messages, 13 records, 398 bytes, 0.096 secs (4145 bytes/sec)

Failures in transfer could be related to port 53 TCP being blocked.

If changes to zonefiles aren't propagating, check that the serial has been incremented.

You can force the slave to re-read all the zones by deleting the cached copies (probably in /var/lib/bind/) and restarting bind. It's safe to do this on a slave because the master retains the original versions.

Check the syslog for configuration errors when restarting bind. The daemon will tell you that a line failed and then that zone will not be loaded at all, while other zones will still work.

Tracking back the root of a problem

From your own desktop, test the mailserver record as below and you should receive an answer section:

# dig MX moff.tech

;; ANSWER SECTION:
moff.tech.        3600  IN    MX    10 mail.moffatt.org.nz.

If that's not working, do the same thing and specifically ask your DNS server the same question:

# dig MX @1.2.3.4 moff.tech

1.2.3.4 must be the IP of your DNS server.

If there is an answer section, the server is doing okay. Maybe your TLD registry records aren't up to scratch. If there is no answer section, go the the DNS server itself and run the command:

# dig MX @localhost moff.tech

If you got no answer section there, then your MX record is set up incorrectly. If you did get an answer section (but none in the previous step), then there could be rules or a misconfiguration in bind that forbids the query from remote hosts.

Don't forget to verify that both of your DNS servers return an answer section. Use the "dig MX @x.x.x.x example.com" for each DNS server IP.

Summary

After sweating blood, all you've managed to do is set up a basic nameserver. Your mailserver is still a long way off. Give up now.

Next up, we're configuring exim4 as a basic mailserver.  Much like this DNS section, it's not over after that. We want a good mailserver, not a basic one.