At this point the /var/vmail directory should be empty yet. You can get a list of all files and directories within by running:
There is probably nothing except perhaps a "lost+found" directory if /var/vmail is on a seperate partition.
Let's now try to send an email to the user firstname.lastname@example.org:
echo test | mail email@example.com
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. Look again:
You should see something like:
Your files may have slightly different numbers. So John has a new email in his inbox. Your /var/log/mail.log will look something like:
postfix/pickup: 2A907A8C: uid=0 from=<root>
postfix/cleanup: 2A907A8C: message-id=<20110416213338.2A907A8C@myserver>
postfix/qmgr: 2A907A8C: from=<root@myserver>, size=306, nrcpt=1 (queue active)
dovecot: deliver(firstname.lastname@example.org): msgid=<20110416213338.2A907A8C@myserver>: saved mail to INBOX
postfix/pipe: 2A907A8C: to=<email@example.com>, relay=dovecot, delay=0.03, delays=0.02/0/0/0.01, dsn=2.0.0, status=sent (delivered via dovecot service)
postfix/qmgr: 2A907A8C: removed
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.
(If you are curious how to send an email to your mail server using a manual SMTP session then read the respective section in the Lenny tutorial. It's also good as an additional test because the "mail" command bypasses a few of Postfix's security features.)
Access the email on disk
Apparently everything went well. To read the email from John's inbox you can use either POP3, IMAP or access the maildir directly. The latter can be done using the console-based "mutt" email client:
mutt -f /var/vmail/example.org/john/Maildir
(You may get asked to create /root/Mail - this is standard procedure. Just answer "yes" or press Enter.)
What you see now are the contents of John's mailbox:
Press enter and you can read the email number 1:
So there is your test email. Press "q" to quit "mutt".
Access the email using IMAP
Actually we just cheated a little as we have accessed John's inbox directly on disk. A better test is to use POP3 or IMAP. And fortunately "mutt" supports IMAP:
mutt -f imap://firstname.lastname@example.org@localhost
You may be prompted to confirm that you are connecting to a mail server with an untrusted SSL certificate. That's okay. In the end you should see the index and email just like in the screenshots above. That worked? Great. Otherwise check your /var/log/mail.log for error messages.
If you still can't get enough and want to run a manual POP3 and IMAP session using TELNET then check out the Lenny tutorial on a complete example.
POP3 versus IMAP
If you wonder what the difference between POP3 and IMAP is:
- 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).