Setting Up and Configuring a Linux Mail Server

Linux Mail Server

Setting up Linux mail server and SMTP (Simple Mail Transfer Protocol) is essential if you want to use email, so we’re going to look at how we can install and configure mail server along with some other email-related protocols, like Post Office Protocol (POP3) and Internet Message Access Protocol (IMAP).

Linux SMTP Server

SMTP stands for Simple Mail Transfer Protocol (SMTP) and it’s used for transmitting electronic mail. It’s platform-independent, so long as the server can send ASCII text and can connect to port 25 (the standard SMTP port).

Sendmail and Postfix are two of the commonest SMTP implementations and are usually included in most Linux distributions.

Sendmail is a free and popular mail server, but it’s not all that secure and doesn’t seem to have been designed for ease of use, which is to say that it’s a bit tricky to get to grips with. Postfix is better in both these regards, however.

Linux Email Server Components

There are three components to a mail service on a Linux email server:

  1. Mail user agent (MUA) is the GUI, the part that lets you write and send emails, like Thunderbird or Outlook.
  2. Mail transport agent (MTA) is the bit that moves the mail (as the name suggests). MTAs like Sendmail and Postfix are the parts that waft your communications from place to place through the ether.
  3. Mail delivery agent (MDA) is the component that sends out messages sent to you on your local machine, so they get to the appropriate user mailbox. Postfix-maildrop and Procmail are examples.

Setup Linux Email Server

In order to configure a Linux mail server, you’ll first need to check if Postfix is already installed. It’s the default mail server on the lion’s share of Linux distributions these days, which is good because server admins like it a lot.

Here’s how to check if it’s already on the system:

$ rpm -qa | grep postfix

If not, this is how you install it on Red Hat distributions:

$ dnf -y install postfix

Next, run it and activate it on system start-up:

$ systemctl start postfix

$ systemctl activate postfix

For distributions based on Debian, like Ubuntu, you’d install them like this:

$ apt-get -y install postfix

As you configure Linux mail server you will receive a prompt to choose how you want to configure your Postfix mail server.

You’ll be presented with these choices:

  • No configuration
  • Internet site
  • Internet with smarthost
  • Satellite system and Local only

Let’s go with the No configuration option for our Linux email server.

Configure Linux Mail Server

After installing the Postfix mail server, you will need to set it up, and most of the files you’ll need for this can be found inside the /etc/postfix/ directory.

You can find the main configuration for Postfix Linux mail server in the /etc/postfix/ file.

This file contains numerous options like:


Use this one to specify the hostname of the mail server, which is where postfix will obtain its emails.

The hostnames will look something like,

You incorporate the hostname this way:

myhostname =

This option is the mail domain that you will be servicing, like

The syntax looks like this: =


All emails sent from this mail server will look as though they came from the one that you specify in this option. You can set this to $

myorigin = $

Use any value that you want for this option but put a dollar sign in front of it like this: $


This option shows you which domains the Postfix server uses for incoming emails to your Linux email server.

You can assign values like this:

mydestination = $myhostname, localhost.$, $, mail.$, www.$


A Postfix Linux mail server can use two modes of delivery:

  • straight to someone’s mailbox.
  • to a central spool directory, which means the mail will sit in /var/spool/mail with a file for every user.

mail_spool_directory = /var/spool/mail


This will let you arrange which servers can relay through your Postfix server.

It should only take local addresses like local mail scripts on your server.

If this isn’t the case, then spammers can piggyback on your Linux mail server. That means your lovely shiny server will be doing the heavy lifting for some bad guys and it will also end up getting banned.

Here’s the syntax for this option:

mynetworks =,


This one determines what message is sent after the client connects successfully.

Consider changing the banner so it doesn’t give away any potentially compromising information about your server.


This option designates which IP protocol version is used for server connections.

inet_protocols = ipv4

When you change any of files used to configure Linux mail server for Postfix, you must reload the service, with this directive:

$ systemctl reload postfix

Of course, we all get distracted and typing things in can often result in mistakes, but you can track down any misspellings that might compromise your Linux mail server using this command:

$ postfix check

Checking the Mail Queue

Things like network failure (and many other reasons) can mean that the mail queue on your Linux email server can end up getting full, but you can check the Postfix mail queue with this command:

$ mailq

If that reveals that its full then you can flush the queue using this command:

$ postfix flush

Look at it again and you should see that your Linux email server queue is clear.

Test Linux Mail Server

Once your configuration is done you need to test your Linux mail server.

The first thing to do is use a local mail user agent such as mailx or mail which is a symlink to mailx.

Send your first test to someone on the Linux mail server and if that works then send the next one to somewhere external.

$ echo "This is the body of the message" | mailx -s "Here we have a Subject" -r "for instance <small [email protected]>" -a /path/to/attachment [email protected]

Then check if your Linux email server can pick up external mail.

If you run into any snags, have a peek at the logs. The Red Hat log file can be found in /var/log/maillog and for Debian versions in /var/log/mail.log, or wherever else the rsyslogd configuration specifies.

I would suggest you review the Linux syslog server for an in-depth clarification on logs and how to set up rsyslogd.

If you run into any more difficulties, take a look at your DNS settings and use Linux network commands to check your MX records.

Fight Spam with SpamAssassin

Nobody likes spam, and SpamAssassin is probably the best free, open source spam fighting ninja that you could hope to have in your corner.

Installing it is as simple as doing this:

$ dnf -y install spamassassin

Then you just start the service and activate it at start-up:

$ systemctl start spamassassin

$ systemctl activate spamassassin

Once you’ve done that, you can see how it’s configured in the /etc/mail/spamassassin/ file.

SpamAssassin runs a number of scripts to test how spammy an email is. The higher the score that the scripts deliver, the more chances there are that it’s spam.

In the configuration file, if the parameter required_hits is 6, this tells you that SpamAssassin will consider an email to be spam if it scores 6 or more.

The report_safe command will have values of 0, 1, or 2. A 0 tells you that email marked as spam is sent without modification, and only the headers will label it as spam.

A 1 or a 2 means that a new report message will be created by SpamAssassin and delivered to the recipient.

A value of 1 indicates that the spam message is coded as content message/rfc822, and if it’s a 2, that means the message has been coded as text or plain content.

Text or plain is less dangerous because some mail clients execute message/rfc822, which is not good if they contain any kind of malware.

The next thing to do is integrate it into Postfix, and the easiest way to do that is with procmail.

We’ll make a file called/etc/procmailrc, and add this to it:

:0 hbfw | /usr/bin/spamc

Then we’ll edit the Postfix configuration file /etc/postfix/ and alter the mailbox_command, thus:

mailbox_command = /usr/bin/procmail

Last but not least, restart Postfix and SpamAssassin services:

$ systemctl restart postfix

$ systemctl restart spamassassin

Unfortunately, SpamAssassin can’t catch everything, and spam messages can still sneak through to fill up the mailboxes on your Linux email server.

But never fear because you can filter messages before they even get to the Postfix server with Realtime Blackhole Lists (RBLs).

Open the Postfix server configuration at /etc/postfix/ and change smtpd_recipient_restrictions option by adding the following options like this:

strict_rfc821_envelopes = yes

relay_domains_reject_code = 554

unknown_address_reject_code = 554

unknown_client_reject_code = 554

unknown_hostname_reject_code = 554

unknown_local_recipient_reject_code = 554

unknown_relay_recipient_reject_code = 554

unverified_recipient_reject_code = 554

smtpd_recipient_restrictions =















Now, restart your postfix Linux mail server:

$ systemctl restart postfix

The above RBLs are the most common ones found, but there are plenty more on the web for you to track down and try.


POP3 and IMAP Protocol Basics

We now know how a SMTP Linux mail server sends and receives emails, but what about other user needs, like when they want local copies of emails to view off-line?

mbox file format isn’t supported; it’s used by many mail user agents such as mailx and mutt.

Due to security concerns, some mail servers restrict access to the shared mail spool directories.

Another class of protocols—called mail access protocols—was introduced to deal with such situations.

The commonest ones are POP and IMAP – Post Office Protocol and Internet Message Access Protocol.

POP’s underlying methodology is very simple: a central Linux mail server is online 24/7 for reception and storage of all user emails.

When an email is sent, the email client relays it through the central Linux mail server using SMTP.

Be aware that the SMTP server and POP server can easily be on the same system, and that this is a common thing to do.

IMAP was developed because previously you couldn’t keep a master copy of a user’s email on the server.

With IMAP, your Linux email server supports three kinds of access:

  • online mode is like having direct access to the Linux email server file system.
  • offline mode feels like POP, where the client only connects to the network to get their mail, and the server won’t keep a copy.
  • disconnected mode lets users keep cached copies of their emails and the server keeps one too.

There are a few different implementations for IMAP and POP, with the most prevalent being dovecot server, which offers both.

POP3, POP3S, IMAP, and IMAPS listen on ports 110, 995, 143, and 993 respectively.

Dovecot Installation

Dovecot is preinstalled on the majority of Linux distributions, and there’s no problem putting it in Red Hat too:

$ dnf -y install dovecot

For Debian, a pair of packages provide the IMAP and POP3 functionality. Here’s how to install them:

$ apt-get -y install dovecot-imapd dovecot-pop3d

You will be prompted to create self-signed certificates for using IMAP and POP3 over SSL/TLS. Select yes and type in the hostname of your system when asked to do so.

Then you can run the service and activate it at start-up like this:

$ systemctl start dovecot

$ systemctl activate dovecot

Configure Dovecot

The main configuration file for Dovecot is /etc/dovecot/dovecot.conf file.
Some varieties of Linux keep the configuration in the/etc/dovecot/conf.d/ directory and then have the include directive include the settings in the files.

Here are a few of the parameters used to configure dovecot:

protocols: the ones you want to support.
protocols = imap pop3 lmtp
lmtp stands for local mail transfer protocol.
listen: IP addresses to listen on.

listen = *, ::

The asterisk means all ipv4 interfaces and :: means all ipv6 interfaces
userdb: user database to authenticate users.

userdb { driver = pam }

passdb: password database two authenticate users.

passdb { driver = passwd }

mail_location: this entry is in the /etc/dovecot/conf.d/10-mail.conf file, and it’s written like this:

mail_location = mbox:~/mail:INBOX=/var/mail/%u

Secure Dovecot

Dovecot features generic SSL certificates and key files used with /etc/dovecot/conf.d/10-ssl.conf

ssl_cert = </etc/pki/dovecot/certs/dovecot.pem

ssl_key = </etc/pki/dovecot/private/dovecot.pem

If you try to connect to a dovecot server and certificates haven’t been signed, then you’ll get a warning, but if you go to a certificate authority you can buy one, so no worries there.

Alternatively, you can point to them using Let’s Encrypt certificates:

ssl_cert = </etc/letsencrypt/live/

ssl_key = </etc/letsencrypt/live/

You’ll need to open dovecot server ports in your iptables firewall by adding iptables rules for ports 110, 995, 143, 993, 25.

Do that and save the rules.

Or if you have a firewall then do this:

$ firewall-cmd --permanent --add-port=110/tcp --add-port=995/tcp

$ firewall-cmd --permanent --add-port=143/tcp --add-port=993/tcp

$ firewall-cmd --reload

Finally, for troubleshooting, check through the log files /var/log/messages, /var/log/maillog, and /var/log/mail.log files.

Linux mail server (and particularly Postfix) is one of the simplest systems you can work with.

Setting up Linux mail server with Plesk

Plesk hosting platform provides administrators with a variety of innovative features including ability to setup all mail services via user-friendly interface. The following article will explain you how to setup and manage  mail services under Plesk