Today I ran a hands-on training session on configuring a MTA with Postfix and Dovecot for LUV. I gave each student a virtual machine running Debian/Jessie with full Internet access and instructions on how to configure it as a basic mail server. Here is a slightly modified set of instructions that anyone can do on their own system.
Today I learned that documentation that includes passwords on a command-line should have quotes around the password, one student used a semi-colon character in his password which caused some confusion (it’s the command separator character in BASH). I also discovered that trying to just tell users which virtual server to login to is prone to errors, in future I’ll print out a list of user-names and passwords for virtual servers and tear off one for each student so there’s no possibility of 2 users logging in to the same system.
I gave each student a sub-domain of unixapropos.com (a zone that I use for various random sysadmin type things). I have changed the instructions to use example.com which is the official address for testing things (or you could use any zone that you use). The test VMs that I setup had a user named “auser”, the documentation assumes this account name. You could change “auser” to something else if you wish.
Below are all the instructions for anyone who wants to try it at home or setup virtual machines and run their own training session.
Table of Contents
Basic MTA Configuration
- Run “apt-get install postfix” to install Postfix, select “Internet Site” for the type of mail configuration and enter the domain name you selected for the mail name.
- The main Postfix configuration file is /etc/postfix/main.cf. Change the myhostname setting to the fully qualified name of the system, something like mta.example.com.
You can edit /etc/postfix/main.cf with vi (or any other editor) or use the postconf command to change it, eg “postconf -e myhostname=mta.example.com“. - Add “home_mailbox=Maildir/” to the Postfix configuration to make it deliver to a Maildir spool in the user’s home directory.
- Restart Postfix to apply the changes.
- Run “apt-get install swaks libnet-ssleay-perl” to install swaks (a SMTP test tool).
- Test delivery by running the command “swaks -f auser@example.com -t auser@example.com -s localhost“. Note that swaks displays the SMTP data so you can see exactly what happens and if something goes wrong you will see everything about the error.
- Inspect /var/log/mail.log to see the messages about the delivery. View the message which is in ~auser/Maildir/new.
- When other students get to this stage run the same swaks command but with the -t changed to the address in their domain, check the mail.log to see that the messages were transferred and view the mail with less to see the received lines. If you do this on your own specify a recipient address that’s a regular email address of yours (EG a Gmail account).
Basic Pop/IMAP Configuration
- Run “apt-get install dovecot-pop3d dovecot-imapd” to install Dovecot POP and IMAP servers.
Run “netstat -tln” to see the ports that have daemons listening on them, observe that ports 110 and 143 are in use. - Edit /etc/dovecot/conf.d/10-mail.conf and change mail_location to “maildir:~/Maildir“. Then restart Dovecot.
- Run the command “nc localhost 110” to connect to POP, then run the following commands to get capabilities, login, and retrieve mail:
user auser
pass WHATEVERYOUMADEIT
capa
list
retr 1
quit - Run the command “nc localhost 143” to connect to IMAP, then run the following commands to list capabilities, login, and logout:
a capability
b login auser WHATEVERYOUMADEIT
c logout - For the above commands make note of the capabilities, we will refer to that later.
Now you have a basically functional mail server on the Internet!
POP/IMAP Over SSL
To avoid password sniffing we need to use SSL. To do it properly requires obtaining a signed key for a DNS address but we can do the technical work with the “snakeoil” certificate that is generated by Debian.
- Edit /etc/dovecot/conf.d/10-ssl.conf and change “ssl = no” to “ssl = required“. Then add the following 2 lines:
ssl_cert = </etc/ssl/certs/ssl-cert-snakeoil.pem
ssl_key = </etc/ssl/private/ssl-cert-snakeoil.key -
- Run “netstat -tln” and note that ports 993 and 995 are not in use.
- Edit /etc/dovecot/conf.d/10-master.conf and uncomment the following lines:
port = 993
ssl = yes
port = 995
ssl = yes - Restart Dovecot, run “netstat -tln” and note that ports 993 and 995 are in use.
- Run “nc localhost 110” and “nc localhost 143” as before, note that the capabilities have changed to include STLS/STARTTLS respectively.
- Run “gnutls-cli --tofu 127.0.0.1 -p 993” to connect to the server via IMAPS and “gnutls-cli --tofu 127.0.0.1 -p 995” to connect via POP3S. The --tofu option means to “Trust On First Use”, it stores the public key in ~/.gnutls and checks it the next time you connect. This allows you to safely use a “snakeoil” certificate if all apps can securely get a copy of the key.
Postfix SSL
- Edit /etc/postfix/main.cf and add the following 4 lines:
smtpd_tls_received_header = yes
smtpd_tls_loglevel = 1
smtp_tls_loglevel = 1
smtp_tls_security_level = may
Then restart Postfix. This makes Postfix log TLS summary messages to syslog and in the Received header. It also permits Postfix to send with TLS. - Run “nc localhost 25” to connect to your SMTP port and then enter the following commands:
ehlo test
quit
Note that the response to the EHLO command includes 250-STARTTLS, this is because Postfix was configured with the Snakeoil certificate by default. - Run “gnutls-cli --tofu 127.0.0.1 -p 25 -s” and enter the following commands:
ehlo test
starttls
^D
After the CTRL-D gnutls-cli will establish a SSL connection. - Run “swaks -tls -f auser@example.com -t auser@example.com -s localhost” to send a message with SSL encryption. Note that swaks doesn’t verify the key.
- Try using swaks to send messages to other servers with SSL encryption. Gmail is one example of a mail server that supports SSL which can be used, run “swaks -tls -f auser@example.com -t YOURADDRESS@gmail.com” to send TLS (encapsulated SSL) mail to Gmail via swaks. Also run “swaks -tls -f auser@example.com -t YOURADDRESS@gmail.com -s localhost” to send via your new mail server (which should log that it was a TLS connection from swaks and a TLS connection to Gmail).
SASL
SASL is the system of SMTP authentication for mail relaying. It is needed to permit devices without fixed IP addresses to send mail through a server. The easiest way of configuring Postfix SASL is to have Dovecot provide it’s authentication data to Postfix. Among other things if you change Dovecot to authenticate in another way you won’t need to make any matching changes to Postfix.
- Run “mkdir -p /var/spool/postfix/var/spool” and “ln -s ../.. /var/spool/postfix/var/spool/postfix“, this allows parts of Postfix to work with the same configuration regardless of whether they are running in a chroot.
- Add the following to /etc/postfix/main.cf and restart Postfix:
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_sasl_path = /var/spool/postfix/private/auth
broken_sasl_auth_clients = yes
smtpd_sasl_authenticated_header = yes - Edit /etc/dovecot/conf.d/10-master.conf, uncomment the following lines, and then restart Dovecot:
unix_listener /var/spool/postfix/private/auth {
mode = 0666
} - Edit /etc/postfix/master.cf, uncomment the line for the submission service, and restart Postfix. This makes Postfix listen on port 587 which is allowed through most firewalls.
- From another system (IE not the virtual machine you are working on) run “swaks -tls -f auser@example.com -t YOURADDRESS@gmail.com -s YOURSERVER and note that the message is rejected with “Relay access denied“.
- Now run “swaks -tls --auth-user auser --auth-password WHATEVER -f auser@example.com -t YOURREALADDRESS -s YOURSERVER” and observe that the mail is delivered (subject to anti-spam measures at the recipient).
Configuring a MUA
If every part of the previous 3 sections is complete then you should be able to setup your favourite MUA. Use “auser” as the user-name for SMTP and IMAP, mail.example.com for the SMTP/IMAP server and it should just work! Of course you need to use the same DNS server for your MUA to have this just work. But another possibility for testing is to have the MUA talk to the server by IP address not by name.
Great Russell,
What a wonderful resource. I like the note about printing out the VM names but I am often amazed that people don’t bring any paper and pen to write stuff down on. I know we might be in an IT era but most people don’t have the ability to remember details accurately. If (when) we/you do something like that again I wouldn’t mind knowing the detail before so I could check it out and help others. I mostly carry a black marker and other teaching stuff – a hangover from my teaching days maybe. I was using it at home a lot recently.
Mike
Students will always find new and interesting ways to break things. If *I* don’t learn something new from a learning session I tend to wonder if I did something wrong in my teaching.
Mike: I’m not a pen person. Part of that is due to being left-handed which causes more pain, difficulty, and mess when I write (left to right writing and books that open from right to left are best for right-handers).
The benefit of printing out hostnames and passwords is that the paper is a physical token. It’s rare for a waiter to be able to remember the dish that each person ordered, remembering students VM names while helping them diagnose all the technical problems they cause themselves is impossible for me.
Matti: As a general concept that makes some sense, but to some extent it depends on the situation. One conference required that I give a training session 3 times and it was a training session that was very similar to ones I’d given before. The last 2 times I definitely didn’t learn anything.
Russell, my comments were in no way intended to be a dig at you – I noticed the left-handedness BTW. It was intended that the people around the room could at least ask a few less unnecessary questions if they could read the WiFi pass-code from the board. Printed slips with numbers on would be great for just about everyone.
It turns out, I think, that we have a fair bit in common (see meetup list etc).
You did a fantastic job – I only saw part of the session – I (re-) learned heaps.
You are likely to know that some people are visual learners – they often ‘fog-over’ when presented with lots of words.
More later
Mike
Mike: don’t worry I didn’t take your comment as criticism. Regarding different learning styles it’s very difficult to get a session like that going so I didn’t have spare time to consider such things.
This is a great guide. Thank you for not dragging in Cyrus SASL which is what guides I followed in the past recommended.