Arch Linux mail server tutorial - part 1 - What is email?

Published on 2017-12-27. Modified on 2021-07-19.

In this tutorial we're going to setup Arch Linux as a mail server for virtual users using openSMTPD and Dovecot. The setup I am going to use is a simple setup for home usage or office usage without webmail or database management of virtual users (though you can easily add that). Instead the users are managed using a simple flat file and they connect to the server using an email client. The setup is very easy to manage and it is very well suited for home usage, if you want to manage your own email, and perhaps friends and family email as well.

Email, what is that?

Of course you know what email is right? Well, before we start setting up a mail server, let's take a look at it anyway :)

In the beginning people where only able to send messages to other people on the same computer. In 1971, the first email was sent by Ray Tomlinson, an American computer programmer who implemented the first email program on the ARPANET system, the precursor to the Internet, and that email formed the basis of how email systems have become today.

The main components of email systems that make it possible to send and receive emails on Internet today are (mainly):

The communication between these components can be illustrated, in a simple form:

  1. Your email client (MSA) contacts your SMTP server (MTA), often the SMTP server of your ISP, and delivers the email to the SMTP server.
  2. The SMTP server reads the domain name of the email address you're sending to (the part of the email address on the right of @) and contacts a DNS server in order to figure out what "exchange server" (another SMTP server) is supposed to receive email on behalf of the domain. On DNS servers, what is called the MX record, contains the name of the target host.
  3. Based on the target host and other factors, the SMTP server then selects an exchange server. The sending SMTP server now acts as a client and connects to the receiving SMTP server in order to deliver the email. In this step two SMTP servers are talking to each other.
  4. The receiving SMTP server accepts the email (if certain conditions are met) and then forwards it to a mail delivery agent (MDA), the POP/IMAP server.
  5. The POP/IMAP server saves messages in the relevant mailbox format. A POP/IMAP may deliver messages directly to storage, or may even forward them over to another SMTP server, if the receiver has enabled "forward", or other protocols such as Local Mail Transfer Protocol (LMTP), a derivative of SMTP designed for this purpose.

Email clients typically use SMTP only for sending messages to a mail server for relaying. For retrieving messages, client applications usually use either IMAP or POP.

This is a simple example. In most cases you'll find several other components in between, such as spam filter servers and anti-virus servers.

So sending and receiving email consists of quite a few steps involving a number of different applications, but not all of these applications are really needed, it's just the way it came to be.

An email client, such as Thunderbird or Claws-mail, could in theory send out email directly to the receiving SMTP server for a domain. The email client could do the DNS lookup by itself and then connect to the receiving SMTP server and deliver the email. However, if the remote SMTP server is down, you need a system that will automatically keep re-sending the email until it is delivered, hence the need for a sending SMTP server. Similarly, in the beginning, not all mail servers were connected all the time because Internet connections were very expensive, so email would be queued and sent in intervals. This is the main reason why the email client relays the email to a SMTP server for delivery. If your email client should act as an SMTP client, you would need to leave your email application running until a message would have been delivered, hence that task is handed over to a server. This function is just not practical in an email client.

Another reason why things has evolved this way is spamming. A number of techniques has been developed in order to combat the huge amounts of spam that gets send out every day. In the year 2011, the estimated figure for spam messages is around seven trillion. Some of these techniques require that the sender of an email is a legit mail server and not anyones email client. ISPs hence often block outgoing communication the SMTP port, block dynamic IP addresses (large parts of the Internet has been blocked), and check that reverse DNS matches forward DNS in order to verify that the domain owner also owns the IP address.

All these things makes in unsuitable for the email client to act as a mail transfer agent (MTA).

As a side note, I am personally against many of the popular spam fighting mechanisms such as spam filtering, virus filtering, and grey listing on mail servers. This stuff doesn't belong on mail servers.

Grey listing is a technique in which an email gets temporary rejected. The sending SMTP server gets "grey listed" and has to try to resend the email, as any good SMTP server by default continues to do for several days. Somebody thought that this would deter spammers from sending out email because many spammers are using virus infested Windows computers for spamming. This however isn't working very well because most spam systems consists of valid SMTP servers that has been compromised, or simply SMTP servers whos owners actually make money by spamming, and these SMTP servers will - as good SMTP servers must - continue to retry to send out the email in 3-4 days.

Have you ever tried to sign up to a newsletter or a forum or some other service only to find that the confirmation link you're supposed to receive is delayed? Well, in most cases, this is caused by grey listing. The only thing grey listing is really good at is to delay peoples email, which is really annoying!

Spam filtering on the mail server is a huge problem. If the spam filter is setup with an aggressive filtering mechanism lots of legit email will be trashed. If it is setup with a moderate filter mechanism, email that gets flagged as spam is delivered in the junk or spam folder and end users often gets confused about what a legit email consists of, not to mention when somebody forgets to check the junk or spam folder for a legit email - you never receive an answer to your email!

A technique to fight spammers is IP blacklisting. There exist many of these lists that are freely available. These lists run with different policies regarding who gets blacklisted. Many use "spam traps" in which specific email addresses are put on web sites or posted on mailing lists. Spammers then automatically crawl the Internet for email addresses to spam. If such a spam trap gets an email then that information is used by the operators of an IP blacklist. But spam traps isn't the only technique used and many times legit mail servers inadvertently gets blacklisted. As such it is very risky to use IP blacklists because you might block email from a legit server! Simple advice: Don't use them!

Many people recommend the use of IP blacklisting lists because people often drown in spam, but I have personally seen very important email get deleted because of these lists and other similar restrictions.

Some of the most popular IP blacklists are:

These are only a few of the many lists that exist.

If you want to see if your IP address has been blacklisted you can use several services online to test. One such free service is

One of the major problems with several of these lists is that if you get blacklisted, it is often very difficult and very time consuming to get of the list again. People whos business depend on sending out email experience very negative consequences when they inadvertently get blacklisted. Often system administrators on such legit mail servers haven't got time to implement the different requirements by blacklists and other anti-spam systems, or they just don't care because it has become too complicated, so they neglect it. And it is perfectly valid not wanting to implement these features because they have absolutely nothing to do with normal mail exchange!

I do acknowledge the reason why these filtering systems was developed in the first place. Receiving several hundred spam emails a day isn't fun at all! But spam fighting isn't something that should be handled on the server, it should be handled by the receiving client, by the user - only! No matter how good the spam filter is, it is only the receiving user who really can determine whether an email is spam or not.

If your mail server ever blocks a single legit email, even if only once, then it has completely failed its purpose and the function for which it was originally designed and you shouldn't be running a mail server!

Besides from boycotting email altogether here are some good advice in how to avoid spam:

Much spam is send using zombie computers, often infected Microsoft Windows computers. Besides from collaborating with NSA Microsoft Windows should not be run on any computer for several reasons.

Enough about spam, let's get back to regular emailing :)

The email client, also known as the Mail User Agent (MUA).

The email client is the program you use to send, receive, and read email on your computer.

You can see a list on Wikipedia that compares email clients

The Simple Mail Transfer Protocol (SMTP) server, also known as the Mail Transfer Agent (MTA)

SMTP is the communication protocol used in the transfer process by which mail is passed between mail servers.

The SMTP server understands very simple text commands. The most common commands are:

HELO - introduce yourself.
EHLO - introduce yourself and request extended mode.
MAIL FROM: - specify the sender.
RCPT TO: - specify the recipient.
DATA - specify the body of the message (To, From and Subject should be the first three lines.).
RSET - reset.
QUIT - quit the session.
HELP - get help on commands.
VRFY - verify an address.
EXPN - expand an address.
VERB - verbose.

When an email client, or another SMTP server acting as a client, is communicating with an SMTP server the commands above is used.

Port 25

SMTP communication between SMTP servers use TCP port 25. Mail clients on the other hand, often submit the outgoing emails to an SMTP server on port 587.

If your ISP is blocking port 25 you cannot setup an SMTP server because it needs to be able to communicate with other SMTP servers on port 25 in order to both send and receive email. Every remote SMTP server expects the connection on port 25 only. You cannot use a non-standard port for SMTP connections going out from your SMTP server to another SMTP server. You need to find another ISP. Some companies offer "smarthost" services in which you can connect to their SMTP server, through non-standard ports, and they will then relay email for you, but that beats the purpose of running your own mail server.

You could also try to explain to your ISP why you want to setup a mail server in the first place and perhaps get port 25 opened up.

Modern mail clients such as (Outlook, Mail, Thunderbird, etc.) shouldn't use port 25, even though it is sometimes possible (depending on the SMTP server setup). It is best to regard port 25 as the internal communication port between SMTP servers. Besides, port 25 is traditionally blocked by many residential ISPs and Cloud Hosting Providers. It is blocked to curb the amount of spam that is relayed from compromised computers or servers. Unless you're specifically managing a mail server, you should have no traffic traversing this port on your computer.

Port 465

This port should not be used any more and IANA has reassigned a new service to this port, but because it was once recognized by IANA as valid, some legacy email systems are still capable of using this connection method. The port is not RFC compliant, don't use it even when the SMTP server supports it.

Port 587

This is called the "submission" port because this is the default port email should be submitted on to an SMTP server. The email client should always use this port for sending out email. This port, coupled with TLS encryption, will ensure that email is submitted securely and following the guidelines set out by the IETF.

Port 2525

This port is not endorsed by the IETF nor IANA. Some email services use this port as an alternate port, which mirrors port 587, in the event port 25 and port 587 are blocked. Because 2525 is a non-traditional high port number, it is typically allowed on consumer ISPs and Cloud Hosting providers. This port also supports TLS encryption. The port is not RFC compliant, don't use it.

The POP and IMAP server, also known the MDA (Mail Delivery Agent)

POP (Post Office Protocol)

When you check your email using POP, your email client connects to the POP server using port 110. In the simplest implementations of POP, the server maintains a collection of text files, one for each email account. When an email arrives, the POP server appends it to the bottom of the recipient's file.

When your email client connects to the POP server it issues a series of commands to bring copies of your email messages to your local computer. Normally, it will then delete the messages from the server.

Like the SMTP server, the POP server understands a simple set of text commands:

USER - enter your user ID.
PASS - enter your password.
QUIT - quit the POP server.
LIST - list the messages and their size.
RETR - retrieve a message, pass it a message number.
DELE - delete a message, pass it a message number.
TOP - show the top x lines of a message, pass it a message number and the number of lines.

IMAP (Internet Message Access Protocol)

With IMAP your email stays on the server, you can then access it from different locations using different email clients. You can also organize your email into folders, and all the folders exist on the server as well. When you search your email, the search occurs on the server and not on your computer (as it does with POP). Your email client connects to the IMAP server using port 143 or port 993 in case TLS is used.

Even though email stays on the IMAP server, most email clients use a cache system to the local computer. This enables you to read email offline, which you have retrieved when you where online.

Local Mail Transfer Protocol (LMTP)

LMTP is an extension of the Simple Mail Transfer Protocol (SMTP). LMTP is an alternative to SMTP for situations where the receiving end does not have a mail queue, such as a mail storage server acting as a Mail Delivery Agent (MDA). LMTP is not intended for use over wide area networks, it is intended for local networks only.

Mail server security

As a system administrator you need to be careful when you setup a mail server. You need to impose control on which users that can use the server. This is very important in order to make sure your SMTP server wont become an "open relay". A server that is accessible on the Internet and does not enforce any kind of access restrictions is known as an "open relay". This is considered a bad practice worthy of blacklisting. You also need to make sure that only authenticated users can read email, and not only that, but also only the email that belongs to them.

Types of restriction may involve any of the following:

The method I am going to use in this tutorial is "authentication using credentials", which is the most flexible system. SMTP Authentication, often abbreviated SMTP AUTH, is an extension of the SMTP in order to log in using an authentication mechanism.

Alright, I think we're ready for the setup. We'll do that in part 2 of the tutorial.