What is a mail server? * The Mail Transfer Agent, Postfix * The Virtual Alias approach * Sending mail * Receiving mail * Simple spam prevention with Postfix
A mail server is a computer that serves as an electronic post office for email. Mail server software is built around agreed-upon, standardised protocols.
With a running mail server on your VPS, you can have all of your mail, from various email accounts, stored on your VPS and access it remotely anytime via an SSH terminal, a web browser (as you would with Hotmail or Gmail), or IMAP/POP3-it to a local mail client (such as Apple Mail, Mozilla Thunderbird or Microsoft Outlook). You can implement spam filters and automatic mail sorting. And of course, set up email accounts for other users on innumerable domains.
To get a clear idea of the different technologies and terminologies involved, here's the path that a typical mail message might follow:
Somebody somewhere creates a mail message using their client email program, otherwise known as a Mail User Agent (MUA). Examples of MUAs include Mozilla Thunderbird and Microsoft Outlook. The message is created and sent to the mail server of that user's account.
Note that the term "mail server" may refer to a computer that is dedicated to the processing of mail, or the suite of tools installed on a server to process, filter and store mail, but is also commonly used to refer specifically to the Mail Transfer Agent (MTA), which is the backbone of any mail server.
The MTA does not interact with people directly like the MUA does; rather, its job is to receive email from another computer and either send it on to wherever it needs to go, or handle final delivery of email.
The MTA then checks the message to determine the recipient, and queries the Domain Name System (DNS) servers to find out which other MTA is responsible for handling email for the recipient in question. It then sends the message to that MTA. MTAs between themselves speak in Simple Mail Transfer Protocol (SMTP). They are sometimes also referred to as SMTP servers.
At this point, the message has traveled from the sender's computer to their mail server, and has reached the mail server which handles email for the intended recipient.
Depending on the network configuration, it's quite possible that the message will be relayed to yet another MTA. But at some point, one MTA will take responsibility for the message and become responsible for delivery to the recipient.
At this time, the MTA will pass the message to a Mail Delivery Agent (MDA). At its core, an MDA is responsible for actually storing the message to disk. Some MDAs do other things as well, such as filtering mail or delivering to subfolders. But it is the MDA that stores the mail on the server.
Now, the recipient checks his/her mail using his/her MUA. The MUA queries the recipient's mail server using one of the standard protocols: IMAP or POP3. This is where an IMAP/POP3 server comes in. When a user's MUA contacts the mail server, the software which answers that request is an IMAP/POP3 server. The server confirms the recipient's identity, then retrieves the list of messages from the mail storage area and returns them to the MUA, where they can be read by the recipient.
This guide will use Postfix as the MTA and later Dovecot as the IMAP/POP3 server and MDA.
The first objective is to get a barebones mail server up and running. This means installing and configuring Postfix on your VPS to enable sending and receiving of mail by way of an SSH terminal.
You should already have a domain pointing to your VPS as described in web server setup. You will now add basic email capability to that domain.
Postfix is a popular MTA that is very quick to set up. Install Postfix on your VPS from your SSH terminal:
And that's it, Postfix should now be installed. Start it up:
To have Postfix automatically start on boot:
It is best to start off with a simple configuration, and then build on it as your needs dictate and your understanding improves.
With the "Virtual Alias" approach that will be described here, every domain hosted on your VPS can have its own email addresses. Each hosted address is aliased to a local system user (or possibly to a remote address).
Proceed to open the Postfix configuration file in Nano:
Scroll through the document (down using CTRL+v, up with CTRL+y), locate and uncomment or edit the following entries to read so:
soft_bounce: when soft_bounce is enabled, mail will remain queued that would otherwise bounce. It's a good idea to turn it on during testing and then turn it back off once you're confident that your mail server is working correctly.
myhostname: just yourdomain.com, not www.yourdomain.com nor mail.yourdomain.com.
mynetworks_style: this is a trust setting. Only trusted SMTP clients (host = those on your VPS) are allowed to relay mail through Postfix.
virtual_alias_domains: list any other hosted domains here, separated by a space. (You may have to add this line.)
home_mailbox: this setting controls how mail is stored for the users. There are two primary storage options of mail in the *NIX world: mbox and Maildir. mbox stores multiple messages - sometimes hundreds or thousands of messages - in a single file. Maildir stores each message in a separate file. mbox and Maildir have wide support across various email software including MTAs and MDAs. Set this option to Maildir-style mail storage. The slash / at the end is required.
Write your changes (CTRL+o then ENTER) and exit Nano (CTRL+x).
Postfix comes configured to send and receive mail as the root user. Checking your mail as root every time is a bad idea. You will need to alias root to your local user by modifying the /etc/postfix/aliases file. Change the settings as follows:
Save and exit.
To redirect emails to specific local users, configure the virtual alias file /etc/postfix/virtual.
In this basic setup, john and sarah are local system users on your VPS. Users john and sarah will receive their respective emails each in their own mailbox. The two addresses admin and help are virtual email aliases and will be delivered to john's mailbox. sarah will also get emails from two other hosted domains (virtual_alias_domains:).
Once you are finished, save, exit Nano, and run the following command to build the virtual alias table:
Now reload Postfix to effect all the changes made above.
With just Postfix, mail can now be sent to and from your VPS. However, for the moment, you will only be able to read emails by accessing them directly on your VPS. You can use the terminal to send out new emails and read emails that Postfix receives.
You can install an IMAP/POP3 server like Courier, Dovecot or Cyrus to access your mail remotely from a machine running Apple Mail, Mozilla Thunderbird, Microsoft Outlook, etc.
You can also install a webmail server like Roundcube or Squirrelmail to access your mail remotely through a browser, like you would do for a Hotmail or Gmail account.
Both these setups will be covered later.
Try sending an email from your terminal with the command sendmail to an outside email account. For example:
Once you enter the command and address, type your message, then ENTER once, and then CTRL-d to send it off. Log into your email account and check it's been received.
Now send a test email from your outside email account to the email addresses that you configured above, such as email@example.com, firstname.lastname@example.org, email@example.com, etc.
There is a basic email client called Mailx already on your Arch Linux VPS. First you need to tell Mailx where to look for mail. In user john's case, issue the following command:
In sarah's case:
Or, logged into your SSH terminal as either john or sarah, just:
You will need to do this every time you log in. Now issue the mail command to see your mail:
Enter the number of the email to read then hit ENTER. Quit Mailx with q and ENTER. Read more about Mailx commands by issuing the man mail command.
Once you have successfully sent and received emails, proceed to Part Two.
If you're having trouble with Postfix, try troubleshooting with this guide.
As you're just fresh from configuring Postfix, now's a convenient time to add some simple spam prevention. The most basic form of spam defence that can be employed on Postfix without requiring any add-ons is HELO restrictions.
At the start of every mail exchange the client side of the connection is required to send a greeting consisting of the text HELO or EHLO, followed by the fully qualified domain name of the connecting host (or a host on behalf of which it acting as a mail proxy). Many spam-sending applications do not bother to send an HELO or EHLO greeting in an attempt to increase their throughput. By requiring that such a greeting is present can reduce obvious spam.
To further increase the rate of spam detection, the HELO or EHLO greeting should contain a valid and fully-qualified domain name that can be resolved to an IP address.
Implement these restrictions by adding the following three lines to the Postfix main configuration file:
The first line configures Postfix to require a valid greeting, while the second requires that this greeting contains a valid and fully-qualified domain name. The third and final line configures the Postfix server to wait to reject mail until the DATA command is issued so that the sending client can be notified of the reason that the message was rejected.
Save and exit, then reload Postfix to effect the changes.
If everything is working, you're ready to move on to Part Two.