So far you have spent considerable time with theory and configuration. Are you worried whether all you did actually leads to a working mail server? Before we do the final steps let’s take a break and verify that everything you did now works as expected.
At this point the /var/vmail directory should be empty or maybe contain an “example.org” directory if you played with the firstname.lastname@example.org account previously. You can get a list of all files and directories within by running:
Although there are not actually any emails on the server yet, you may still get somethinng along the lines of:
/var/vmail /var/vmail/example.org /var/vmail/example.org/john /var/vmail/example.org/john/.dovecot.sieve /var/vmail/example.org/john/sieve /var/vmail/example.org/john/sieve/roundcube.sieve /var/vmail/example.org/john/sieve/tmp /var/vmail/example.org/john/Maildir /var/vmail/example.org/john/Maildir/subscriptions /var/vmail/example.org/john/Maildir/maildirfolder /var/vmail/example.org/john/Maildir/new /var/vmail/example.org/john/Maildir/cur /var/vmail/example.org/john/Maildir/dovecot-uidlist /var/vmail/example.org/john/Maildir/dovecot-uidvalidity /var/vmail/example.org/john/Maildir/.INBOX.test /var/vmail/example.org/john/Maildir/.INBOX.test/maildirfolder /var/vmail/example.org/john/Maildir/.INBOX.test/new /var/vmail/example.org/john/Maildir/.INBOX.test/dovecot.index.log /var/vmail/example.org/john/Maildir/.INBOX.test/cur /var/vmail/example.org/john/Maildir/.INBOX.test/dovecot-uidlist /var/vmail/example.org/john/Maildir/.INBOX.test/tmp /var/vmail/example.org/john/Maildir/dovecot-uidvalidity.5ddc842b /var/vmail/example.org/john/Maildir/tmp
Basically the schema you see here is /var/vmail/DOMAIN/USER/Maildir/…
Every IMAP mail folder then has three subdirectories:
new– every file here is an email that was stored in this mail folder but not yet read
cur– the same but for email that has been read already
tmp– for temporary actions by the mail server
According to our Dovecot configuration the mail folders are nested like this:
- …/Maildir/new/… – the main inbox
- …/Maildir/.INBOX.reddit/new/… – the “reddit” mail folder below the inbox
- …/Maildir/.INBOX.servers.inga/new/… – the “servers”/”inga” mail folder below the inbox
If you do not use the legacy scheme with “separator = .” your directories will rather look like:
- …/Maildir/new/… – the main inbox
- …/Maildir/INBOX/reddit/new/… – the “reddit” mail folder below the inbox
- …/Maildir/INBOX/servers/inga/new/… – the “servers”/”inga” mail folder below the inbox
To check for obvious configuration error in Postfix please run:
Did you get the error…
“error: open database /etc/aliases.db: No such file or directory“? Don’t worry. Just run the “newaliases” command to create a new machine-readable file from what aliases were defined in the
Very likely you will get this error: “postfix/postfix-script: warning: symlink leaves directory: /etc/postfix/./makedefs.out“. That is a harmless bug of the Debian package that can safely be ignored.
If you get errors about missing values in smtpd_recipient_restrictions and compatibility levels then please do as the log says: “postconf compatibility_level=2” and restart Postfix.
Send a test email
It is time to send a new email into the system. Open a new terminal window and run
tail -f /var/log/mail.log
to see what the mail server is doing. Now let’s send an email to John. My favorite tool for mail tests is swaks that you installed earlier. In a second terminal run:
swaks --to email@example.com --server localhost
If all works as expected your mail.log will show a lot of technical information about the email delivery. Let me explain what happens at each stage.
postfix/smtpd: connect from localhost.localdomain[127.0.0.1]
Postfix receives an incoming SMTP connection.
postfix/smtpd: 8BA46A0A3A: client=localhost.localdomain[127.0.0.1]
Postfix assigns a unique ID (8BA46A0A3A) to this connection so that you see which log lines belong together. This is especially important with busy mail servers where multiple mails are handled in parallel.
postfix/cleanup: 8BA46A0A3A: firstname.lastname@example.org
swaks created a unique message id to the email which helps you identify specific mails in the log file.
postfix/qmgr: 8BA46A0A3A: email@example.com, size=485, nrcpt=1 (queue active)
The sender was firstname.lastname@example.org. This is logged after swaks sent the “MAIL FROM” line during the SMTP dialog.
postfix/smtpd: disconnect from localhost.localdomain[127.0.0.1] ehlo=1 mail=1 rcpt=1 data=1 quit=1 commands=5
The SMTP communication ends. Postfix has now received and queued the email.
dovecot: lmtp(29237): Connect from local
Postfix connects to Dovecot to hand over the email via the LMTP interface.
dovecot: lmtp(email@example.com)<29237><2PJTIh033V01cgAARGEcaw>: sieve: firstname.lastname@example.org: stored mail into mailbox 'INBOX.test'
Dovecot received the email and even evaluated John’s sieve rule which made the email get stored to the ‘test’ folder of his mailbox.
dovecot: lmtp(29237): Disconnect from local: Client has quit the connection (state=READY)
The LMTP connection between Postfix and Dovecot is closed.
postfix/lmtp: 8BA46A0A3A: email@example.com, relay=webmail.example.org[private/dovecot-lmtp], delay=0.01, delays=0/0/0/0.01, dsn=2.0.0, status=sent (250 2.0.0 firstname.lastname@example.org 2PJTIh033V01cgAARGEcaw Saved)
This is the one of the most interesting lines in your mail log. It tells you what happened with a certain email. In this case it says that it was handed over to dovecot-lmtp and that the delivery was successful (status=sent). The status codes like 2.0.0 are defined in RFC 3463 and work similar to status codes in HTTP. Codes beginning with ‘2’ are good. Those with ‘4’ are temporary errors. And ‘5’ stands for a permanent failure.
Your output may look slightly differently. Just focus on the parts that are printed in bold letters. If everything worked as expected Postfix has accepted the email and forwarded it to Dovecot which in turn wrote the email in John’s maildir. If you get any errors in the log file then try to understand the error message and find the cause of the problem before you proceed.
Dovecot has now created a directory structure for John and created a new file:
/var/vmail/ […] /var/vmail/example.org/john/Maildir/new/1515485447.M404984P2636.mail,S=510,W=522 […]
The file may have a different name on your system – that’s okay. The file name printed in bold letter depicts the actual email file. It is the only file in the “new” folder.
Accessing the email as a file on disk
The file just contains the email:
Return-Path: <email@example.com> Delivered-To: firstname.lastname@example.org Received: from mail.example.org by mail.example.org (Dovecot) with LMTP id iHHHEwd5VFpMCgAA3BOsLQ for <email@example.com>; Tue, 09 Jan 2018 09:10:47 +0100 Received: bymail.example.org (Postfix, from userid 0) id 30B4B41A98; Tue, 9 Jan 2018 09:10:47 +0100 (CET) Message-Id: <20180109081047.30B4B41A98@mail.example.org> Date: Tue, 9 Jan 2018 09:10:47 +0100 (CET) From: firstname.lastname@example.org (root) Di 9. Jan 09:10:47 CET 2018
If anything went wrong then carefully check the last lines of your /var/log/mail.log. It will very likely point you to the problem. Or read the troubleshooting section. Or just add a comment to this page and ask other readers for help.
You can also use a slightly more comfortable tool to access Maildirs that will come handy for you as a mail server administrator: “mutt”.
mutt -f /var/vmail/example.org/john/Maildir
(You may get asked to create /root/Mail – this is standard procedure. Just press Enter.)
What you see now are the contents of John’s mailbox:
Using mutt is a nice way to check mailboxes while you are logged in to the mail server.
To reiterate what happens when you receive an email:
- Postfix receives the email (using the “sendmail” command in this example – but usually through the network using the SMTP protocol from other servers)
- Postfix talks to Dovecot via LMTP and hands over the email
- Dovecot write the email file to disk
Accessing the email via IMAP (Roundcube)
Now that the email has been delivered you can talk to Dovecot using the IMAP protocol to retrieve your email again. Are you still logged in via the Roundcube webmail interface? Then just reload and you will see the email:
Accessing the email via IMAP (mutt)
In the last section we used mutt to access the Maildir directly on disk. But remember that mutt also speaks IMAP:
mutt -f imaps://email@example.com@localhost
Does it show you the email now? Great.
Access the email through IMAP (desktop client)
Your users are not likely to use “mutt” to read their email – unless they are immortal console nerds. So of course you can use a graphical mail client to access John’s emails. If you use Thunderbird, Evolution, A**le Mail or some other IMAP client then feel free to configure a new IMAP account and connect to the server. Remember that the user name and email address are both “firstname.lastname@example.org” and the password is “summersun”.
POP3 versus IMAP
Aside from talking IMAP Dovecot also knows how to speak POP3. But let’s face it – POP3 is dead. I do not offer it to my users any more. But as your users may ask let’s quickly review the differences of the two protocols:
- POP3 (Post Office Protocol) is a simple protocol that lets you fetch email from a single mailbox. It is usually used to collect all emails, though you can also leave them on the server but this is a bit of a hack and you can’t create multiple folders on the server to sort your mail. It saves space on the mail server because the email gets moved to the user’s hard disk on their computer. But they won’t be able to access the same email from another computer. Besides you cannot create multiple folders on the server to sort your mail. There is just the inbox. This variant is antiquated and not exactly user-friendly.
- IMAP (Internet Messaging Application Protocol) is predominantly focused upon leaving your mail on the server but you can also collect it like POP3. The inbox is where your incoming emails are stored but users can also maintain folders and move emails to them. But users can move emails to different directories. IMAP is useful when you want to access your email from different locations without losing mail because you fetched it from another location. The drawback is that lazy users leave their mail on the server thus filling up your server’s hard disk (unless you use quotas).