Having your own mail server is very useful, though surprisingly hard to configure. Generally speaking there are actually two components in a standard linux mail server install. There is the Mail Transfer Agent [MTA] and the Mail Delivery Agent [MDA]. For this install I’ll be using Postfix as the MTA and Dovecot as the MDA

The MTA handles relaying mail between different servers. It decides what to do with email from the outside world, and whether a particular user is allowed to send email using your server. It handles both incoming and outgoing SMTP. Postfix hands off local delivery (that is, the actual saving of the mail files on the server) to Dovecot’s Local Mail Transfer Protocol service (LMTP). Postfix also lets Dovecot take care of authentication before users are allowed to send email from the server.

The MDA is the part that end-users interact with. There are two main protocols in use by the MDA, POP3 and/or IMAP (each have a secure variant, and have different pros/cons). For this setup I’m ignoring the options and just configuring IMAPS – this is basically IMAP over an SSL/TLS connection (and won’t be using SSL). The IMAP/POP3 server handles requests from users who want to log in and check their email. Dovecot’s LMTP service functions as the Mail Delivery Agent (MDA) by saving mail files on the server. Dovecot also handles all authorization.

Basic Requirements

• A domain name – in this case flat-planet.net
• A hostname for the server e.g. mail.flat-planet.net
• An SSL certificate for the server hostname – see this post on the process for this

DNS Configuration

A specific type of DNS record is used for e-mail. This is known as the Mail Exchange [MX] record. The characteristic payload information of an MX record is the fully qualified domain name of a mail host and a preference value. The host name must map directly to one or more address record (A, or AAAA) in the DNS, and must not point to any CNAME records.

Section 10.3 of RFC 2181 states:

10.3. MX and NS records

The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias. Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. This domain name must have as its value one or more address records. Currently those will be A records, however in the future other record types giving addressing information may be acceptable. It can also have other RRs, but never a CNAME RR.

Searching for either NS or MX records causes “additional section processing” in which address records associated with the value of the record sought are appended to the answer. This helps avoid needless extra queries that are easily anticipated when the first was made.

Additional section processing does not include CNAME records, let alone the address records that may be associated with the canonical name derived from the alias. Thus, if an alias is used as the value of an NS or MX record, no address will be returned with the NS or MX value. This can cause extra queries, and extra network burden, on every query.

But since I’m hosting on a residential connection I don’t have a static IP, and so I’m using a CNAME record (not an uncommon practice, even among people who have static IPs and should know better).

Colin:~ $ dig flat-planet.net MX

; <<>> DiG 9.8.3-P1 <<>> flat-planet.net MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32916
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;flat-planet.net.        IN    MX

;; ANSWER SECTION:
flat-planet.net.    1799    IN    MX    10 mail.flat-planet.net.

;; Query time: 68 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Dec 27 12:05:18 2014
;; MSG SIZE  rcvd: 54

Colin:~ $ dig mail.flat-planet.net MX

; <<>> DiG 9.8.3-P1 <<>> mail.flat-planet.net MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16794
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;mail.flat-planet.net.        IN    MX

;; ANSWER SECTION:
mail.flat-planet.net.    1402    IN    CNAME    colinmacg.no-ip.info.

;; AUTHORITY SECTION:
no-ip.info.        59    IN    SOA    nf1.no-ip.com. hostmaster.no-ip.com. 2107200777 600 300 604800 600

;; Query time: 117 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Sat Dec 27 12:05:39 2014
;; MSG SIZE  rcvd: 132

At this point a 3rd query is required to resolve the no-ip.info domain to the actual IP address.

It should be noted that the mail will be considered more likely to be spam (by spamassassin, amongst others) as the reverse DNS lookup on the IP address will show it as belonging to your ISP rather then your domain, but that alone is generally not enough.

Postfix

Postfix has two main config files: main.cf, which specifies what you would think of as config options, and master.cf, which specifies the services postfix should run.

master.cf

Here we have the smtp daemon enabled, and we are directing it through SpamAssassin as our content filter

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtp inet n - - - - smtpd
      -o content_filter=spamassassin

...

spamassassin unix - n n - - pipe user=debian-spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

main.cf

Main points here are:

• Add in our cert and key for TLS
• Enable TLS
• Disable SSLv2 and SSLv3 – these are deprecated anyway, and with POODLE (CVE-2014-3566) we should explicitly disable these.
• The use of Mail Directories rather then the default
• Configuring the use of SASL
• Locking down smtpd and the HELO command

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/mail-cert.crt
smtpd_tls_key_file=/etc/ssl/private/mail-key.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_tls_protocols = !SSLv2, !SSLv3

home_mailbox = Maildir/
mailbox_transport = lmtp:unix:private/dovecot-lmtp

# SASL  begins here
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = flat-planet.net
smtpd_tls_auth_only = yes

smtpd_recipient_restrictions =
     permit_sasl_authenticated,
     permit_mynetworks,
     reject_unauth_destination

smtpd_helo_required = yes
smtpd_helo_restrictions =
     permit_mynetworks,
     permit_sasl_authenticated,
     reject_invalid_helo_hostname,
     reject_non_fqdn_helo_hostname,
     reject_unknown_helo_hostname
check_helo_access hash:/etc/postfix/helo_access

Dovecot

Dovecot allows users to log in and check their email using POP3 and IMAP. In this section, you’ll configure Dovecot to force users to use SSL when they connect so that their passwords are never sent to the server in plain text. Users will have to connect using the standard SSL ports – 993 for IMAP and 995 for POP3 – and only those ports. Dovecot’s LMTP service will function as the MDA and store incoming messages in the proper locations on the server. Dovecot will also be handling all user authentication for mail. In this case I’m only worried about IMAP over SSL/TLS.

Dovecot 2 uses a number of different configuration files. The primary configuration file contains a few directives, and then several inclusions of other configuration files. This helps to separate different configuration parameters logically so they’re not all grouped together in one file. This is a major change from Dovecot 1, where virtually everything was configured in the same file.

For my setup the following files are modified (in /etc/config/dovecot/conf.d):

• 10-auth.conf
• 10-mail.conf
• 10-master.conf
• 10-ssl.conf
• 20-lmtp.conf
• 90-sieve.conf

10-auth.conf

Some configuration for Sieve and LMTP later on. We need it to strip the domain from the username and look that part up:

auth_username_format = %Ln

10-mail.conf

Rather then using mbox, I prefer the Maildir approach so modify the file like so:

#mail_location = mbox:~/mail:INBOX=/var/mail/%u
mail_location = maildir:~/Maildir

10-master.conf

Set Dovecot to listen to authentication requests from Postfix over unix sockets rather then network ports, and enable the imaps listener. I’m not opening IMAP to external networks so I’ll leave it enabled for now and disable once I’m sure all is working:

service imap-login {
  inet_listener imap {
    port = 143
  } 
  inet_listener imaps {
    port = 993
    ssl = yes
  }

service auth { 
        unix_listener /var/spool/postfix/private/auth { 
                    mode = 0660 
                    user = postfix 
                    group = postfix 
        } 
}
service lmtp {
        unix_listener /var/spool/postfix/private/dovecot-lmtp {
                    mode = 0666
 }
}

10-ssl.conf

Here I enable SSL, point it towards the keys (the < is not a typo) and disable the ciphers and protocols I don’t want running (SSLv2 and v3).

# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = yes
...
ssl_cert = </etc/ssl/certs/mail-cert.crt
ssl_key = </etc/ssl/private/mail-key.key

...

# SSL protocols to use
ssl_protocols = !SSLv3
...
# SSL ciphers to use
ssl_cipher_list = ALL:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL

20-lmtp.conf

Configure LMTP to allow the recipient address to include the detail of the mail folder you want to put it in, and to enable the sieve plugin (more on that later).

# When recipient address includes the detail (e.g. user+detail), try to save
# the mail to the detail mailbox. See also recipient_delimiter and
# lda_mailbox_autocreate settings.
lmtp_save_to_detail_mailbox = yes

protocol lmtp {
# Space separated list of plugins to load (default is global mail_plugins).
     mail_plugins = $mail_plugins sieve
     postmaster_address = [email protected]
}

90-sieve.conf

Configuration for sieve to allow sorting of the SpamAssassin tagged mails.

plugin {
# The path to the user's main active script. If ManageSieve is used, this the
# location of the symbolic link controlled by ManageSieve.
     sieve = ~/.dovecot.sieve

...
     recipient_delimiter = +

SpamAssassin

SpamAssassin is a perl based e-mail filtering solution. It  uses a variety of spam-detection techniques, that includes DNS-based and fuzzy-checksum-based spam detection, Bayesian filtering, external programs, blacklists and online databases.

As usual, install with:

sudo apt-get update
sudo apt-get install spamassassin

The configure with the file /etc/spamassassin/local.cf and restart. Main configurations is:

• Rewrite the subject line to include the SPAM score
• Modify the headers only – don’t change the body
• Set the required score for something to be marked as SPAM (default is 5)
• Tell it to use Bayesian statistical analysis and enable auto-learning

rewrite_header Subject [***** SPAM _SCORE_ *****]
report_safe 0
required_score 3.0
use_bayes 1
bayes_auto_learn 1

And set ENABLED to 1 in /etc/defaults/spamassassin and restart:

sudo service spamassassin start

 Filtering and Sieve

Install lmtp and sieve

sudo apt-get update
sudo apt-get install dovecot-sieve dovecot-lmtp

Restart Postfix and Dovecot

sudo service postfix reload
sudo service dovecot reload

Add the filter to your home folder in ~/.dovecot.sieve

require ["fileinto"];
# Move spam to spam folder
if header :contains "X-Spam-Flag" "YES" {
         fileinto "Spam";
         # Stop here so that we do not reply on spams
         stop;
}

When SpamAssassin marks emails as Spam it adds X-Spam-Flag: YES to the headers. This rule checks the headers and sends mail to the spam folder if that flag exists.

Does it work?

Apparently so – a fake FedEX mail was intercepted and placed in the SPAM folder. From looking at the mail header I can see the SpamAssassin analysis:

X-Spam-Flag: YES
X-Spam-Level: **********
X-Spam-Status: Yes, score=10.3 required=3.0 tests=HTML_FONT_SIZE_LARGE,
HTML_MESSAGE,KB_DATE_CONTAINS_TAB,MIME_HTML_ONLY,MISSING_MID,     RCVD_IN_BL_SPAMCOP_NET,RCVD_IN_BRBL_LASTEXT,RCVD_IN_XBL,RDNS_NONE,TAB_IN_FROM
autolearn=no version=3.3.2
X-Spam-Report:
* 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net
* [Blocked - see <http://www.spamcop.net/bl.shtml?211.54.17.252>]
* 1.6 RCVD_IN_BRBL_LASTEXT RBL: RCVD_IN_BRBL_LASTEXT
* [211.54.17.252 listed in bb.barracudacentral.org]
* 0.7 RCVD_IN_XBL RBL: Received via a relay in Spamhaus XBL
* [211.54.17.252 listed in zen.spamhaus.org]
* 3.8 KB_DATE_CONTAINS_TAB KB_DATE_CONTAINS_TAB
* 0.4 TAB_IN_FROM From starts with a tab
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.0 HTML_FONT_SIZE_LARGE BODY: HTML font size is large
* 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
* 0.1 MISSING_MID Missing Message-Id: header
* 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS