Chapter 8. SMTP

Table of Contents

Postfix Mail Service Introduction
Postfix Installation
SMTP Configuration
Postfix MX Record
SMTP Firewall
mailx Command Line Mailer
Testing & Troubleshooting Email
SMTP Check Point

Postfix Mail Service Introduction Top of Page

In this chapter, we will configure the email system. By default, CentOS and Red Hat use the Postfix email service. The "out of the box" installation of Postfix is close to workable. There are seven essential directives that need to be modified. Those directives are listed below and expanded with details further down in this document.

  1. Activate and modify 'myhostname' directive.
  2. Activate and modify the 'mydomain' directive.
  3. Activate and modify the 'myorigin' directive.
  4. Alter the 'inet_interfaces' directive.
  5. Activate and modify the 'mydestination' directive.
  6. Activate and modify the 'mynetworks_style' directive.
  7. Activate and modify the 'mynetworks' directive.
[Warning] Email Configuration and SPAM

Email configuration can be a complex undertaking. One misconfigured directive can lead to failure or unwanted results. We are undertaking a simple, unsecured configuration that will work for the purpose of this class. In the event that this learning environment is to remain intact and online, additional measures to secure the email configuration should be put into place. In the event that unauthorized access to the machine, or unwanted relaying, cause the machine to become a tool for Spammers, the machine may become black-listed or blocked by RackSpace. (See DNS Blackhole List (DNSBL) on Wikipedia or for details.) If the machine is to handle mail regularly for several users, the installation of both Apache SpamAssassin and ClamAV Anti-Virus are recommended. See Postfix Howtos and FAQs for several configuration tutorials. Additionally, see the Hardening guide for Postfix 2.x for a simple, direct hardening guide.

Postfix Installation Top of Page

Typically, Postfix is installed by default. This can be verified by the commands listed below. If it's not installed, issue the command `yum -y install postfix`.

Figure 8.1. Postfix Configuration Image #1

Postfix Configuration Image #1

The commands listed above show verification that Postfix is installed, that it's set to start when the machine boots, and that the process is currently running. If running the command `which postifx` does not output the return as listed above, run the install command as shown.

SMTP Configuration Top of Page

Now that we're sure the Postfix packages are installed and the service is functional, it's time to configure it for our machine. The screenshots below will take you through this process. The Postfix configuration files are in the '/etc/postfix' directory.

Figure 8.2. Postfix Configuration Image #2

Postfix Configuration Image #2

Our configuration tasks need to occur in '', as indicated. First we back that file up as we've done before. Next, edit the file with 'vi', or your editor of choice.

Figure 8.3. Postfix Configuration Image #3

Postfix Configuration Image #3

The image above shows four configuration directives (in orange) that need to be set/changed. Make sure to change any instance of with <>. Also note that the localhost directive has been commented out.

Figure 8.4. Postfix Configuration Image #4

Postfix Configuration Image #4

The screenshot above shows the entries that need to be present for the 'mydestination' directive.

Figure 8.5. Postfix Configuration Image #5

Postfix Configuration Image #5

This images shows two directives, 'mynetworks_style', and 'mynetworks'. Make sure to enter the correct IP address of your machine, not the one listed. Also, the /32 part is important. Make sure to tack that on as shown.

Figure 8.6. Postfix Restart

Postfix Restart

After all these configuration changes, we need to restart the Postfix service, as indicated.

Postfix MX Record Top of Page

    bobc@filbert ~/git/webserver7/
    --> dig mx
    ; <<>> DiG 9.10.3-P4-RedHat-9.10.3-13.P4.fc23 <<>> mx
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64481
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

    ; EDNS: version: 0, flags:; udp: 4096
    ;                      IN      MX

    ;; ANSWER SECTION:               300     IN      MX      10

    ;; AUTHORITY SECTION:               93995   IN      NS               93995   IN      NS

    ;; ADDITIONAL SECTION:     74965   IN      A     74965   IN      A

    ;; Query time: 97 msec
    ;; SERVER:
    ;; WHEN: Fri Jul 29 10:48:10 CDT 2016
    ;; MSG SIZE  rcvd: 164

    bobc@filbert ~/git/webserver7/

The command output above shows how to verify that there is a DNS MX record in place for this domain. We set this up previously. See the section called "Introduction to DNS Configuration" for details. Email and DNS are closely tied together for functionality. Without the MX record in place, it won't be possible to route mail properly over the Internet. Please make sure that your MX records points to your machine, not to another machine. In the instance above, I've set mail to be handled by another machine - which is very common. For this class, make sure that a) you have an MX record, & b) that your MX record points directly to your machine.

SMTP Logs Top of Page

The mail logs are our best friends when it comes to troubleshooting mail delivery. The series of images below gives an overview of what we're dealing with. We're going to troubleshoot a problem with mail delivery, and the section called "Testing & Troubleshooting Email" below gives step-by-step instructions on how to use the mail logs to figure out the problem and solution.

Figure 8.7. Postfix Log Image #1

Postfix Log Image #1

The image above shows where and what the mail logs are: '/var/log/maillog'. Note that they are rotated on a regular basis, and the older ones are saved with a date in the name.

Figure 8.8. Postfix Log Image #2

Postfix Log Image #2

This image gives a preview of entries in a maillog. There is a wealth of information logged on each line. It may see cryptic, but each entry gives crucial information to help solve issues.

SMTP Firewall Top of Page

Configuring the Firewall to permit email traffic isn't difficult, as we've been through this exercise several times. In the process outlined below, we'll open port 25.

Figure 8.9. Postfix Firewall Image #1

Postfix Firewall Image #1

This first command opens port 25 in the firewall. The second command reloads the firewall rules. Then the command `iptables -vnL | grep 25` shows that we were successful.[32]

Figure 8.10. Postfix Firewall Image #2

Postfix Firewall Image #2

Finally, as indicated, port 25 is now open, along with several other ports that apply to other services. The output above is a part of what was returned by the command `iptables -vnL`.

mailx Command Line Mailer Top of Page

In order to send mail, we need a client application that will compose and send the message. We'll use the mailx utility. The screen shot below shows installation of the mailx utility.

Figure 8.11. mailx Image #1

mailx Image #1

First we check to see if mailx is installed by using the which command. As shown, it isn't installed so the next step installs mailx. Fnally, as shown, the mailx utility is successfully installed.

Figure 8.12. mailx Image #2

Using the command line mailx client.

This image shows the mailx utility in action. The steps are listed below.

  1. Type 'mailx -s "<subject>" \' NOTE the double quotes around the subject (-s) and the backslash. Press ENTER.[33]
  2. On the next line, enter the email account that the message will be sent to. Press ENTER.
  3. Next type the body of the email message. Press ENTER.
  4. On an empty line, press CTRL + D and mailx will send the message and display EOT.

Figure 8.13. mailx Image #3

mailx Image #3

The image above shows checking mail with mailx. In the listing, there are three messages that were unable to be delivered. Finally, in #4, there is receipt of a message that was sent to my Gmail account.

You are now ready to send an email message from your server. Please do so at this time.

Testing & Troubleshooting Email Top of Page

Now that we have sent an email from our system, the log files will tell us how things went. The list immediately below gives a game plan for checking the status of email delivery & receipt. Testing email configuration can be a tedious and time-consuming undertaking. There is a process that will help if the person doing the troubleshooting can remain patient and systematic. The following is a general strategy for troubleshooting the mail process:

  1. To test mail delivery and receipt, it helps to have access to the servers and the log files of both sending & receiving machines. In most cases, that's not possible. In our situation, the log files of the sending server are all that we can work with.
  2. The first thing to verify is whether the machine being configured can send email. Gmail helped with this step.[34]
  3. Once the machine being configured can successfully send email, the next thing to check is whether it can receive email.
  4. It's best to have a local user account to send mail from. Try to not use the root account.
  5. Since our server operates at runlevel 3, which has no GUI (graphical) front end, we need to use a command-line email client. The best ones I've found, in order of complexity as well as functionality, are 'mailx', 'mutt', and Alpine. Use of these utilities is not difficult, but may take a little getting used to. Watch the on-screen listings and prompts and you can't go wrong.
  6. Remain systematic and watch the log files. The answers to failures are almost always given. If you have problems, go back through the configuration on your machine and verify (once again) that it matches what's given above.
  7. If you have recurring problems, check the firewall. Lower the firewall to test if that's the cause of the problem.[35] If email works with the firewall down, the problem is with the firewall configuration.
[Note] Watch the Timestamps

An important part of the exchange listed above, which is present in all the listings below, is the time differential of the exchange as listed. The total time of the exchange of this email from connection to disconnection is less than one second. This means that the server is working well and there is no backlog of email messages or delays in any of the services involved. If the time differential at any point was longer, that would indicate where a delay of some type was occurring. Watch the timestamps in the listings below to see how the servers are responding.

Listed below are three snippets of log files that show a successful send, a successful receipt, and a failed send - with the solution to the failure.

    Aug  9 21:53:48 alpha postfix/pickup[6316]: 93BF413E152: uid=500 from=<bob> 1
    Aug  9 21:53:48 alpha postfix/cleanup[6324]: 93BF413E152: message-id=<> 2
    Aug  9 21:53:48 alpha postfix/qmgr[6317]: 93BF413E152: from=<>, size=927, nrcpt=1 (queue active) 3
    Aug  9 21:53:49 alpha postfix/smtp[6448]: 93BF413E152: to=<>,[2607:f8b0:4001:c03::1b]:25, \
         delay=0.9, delays=0.06/0.01/0.09/0.74, dsn=2.0.0, status=sent (250 2.0.0 OK 1407621229 db13si10819518igc.37 - gsmtp) 4
    Aug  9 21:53:49 alpha postfix/qmgr[6317]: 93BF413E152: removed 5


The message is coming from the local Linux user bob.


The unique message ID number is stated.


The message is currently being held in the queue, and the from email address is stated..


This line shows a summary of what happened when our server connected to and delivered the message to the Google mail server. Note the status=sent line as well as the return code 250 OK.


The message has been removed from the send queue due to successful delivery.

The above program listing shows the steps for a successful delivery of an email message from the viewpoint of our server. In this particular exchange, our mail server has successfully delivered an email message to a Google mail relay for delivery. Take a close look at the timestamps. There were five (or more) interactions in a second or less. That's swift, the server is working well.

    Aug  9 21:52:11 alpha postfix/smtpd[6320]: connect from[] 1
    Aug  9 21:52:12 alpha postfix/smtpd[6320]: 0905C13E151:[] 2
    Aug  9 21:52:12 alpha postfix/cleanup[6324]: 0905C13E151: message-id=<> 3 
    Aug  9 21:52:12 alpha postfix/qmgr[6317]: 0905C13E151: from=<>, size=2292, nrcpt=1 (queue active) 4 
    Aug  9 21:52:12 alpha postfix/local[6325]: 0905C13E151: to=<>, relay=local, delay=0.51, delays=0.45/0.01/0/0.05, dsn=2.0.0, status=sent (delivered to mailbox) 5 
    Aug  9 21:52:12 alpha postfix/qmgr[6317]: 0905C13E151: removed 6 
    Aug  9 21:52:12 alpha postfix/smtpd[6320]: disconnect from[] 7


The mail server at Google has connected to our mail server.


The Google mail server has identified itself.


The unique ID of the mail message is stated.


The sender (who it's from) of the message is stated. Note that the mailserver is talking to the queue manager in this step.


Who the messages is to be delivered to is stated. Note that the status=sent clause gives the result of this command, which is success.


Upon successful delivery to the user's mailbox, the message is removed from the Postfix queue.


The Google mail server is now disconnected.

The above program listing shows the steps for a successful receipt of an email message from the viewpoint of our server. In this particular exchange, the "play-by-play" unfolds from the initial connection to final disconnection between Google and our mail server. Once again, less than a second to receive the message.

    Jul 29 13:05:04 alpha postfix/master[11110]: daemon started -- version 2.10.1, configuration /etc/postfix 1
    Jul 29 13:18:45 alpha postfix/smtp[12003]: 17BCE62284: to=<>,[2607:f8b0:4003:c06::1b]:25, delay=0.38, \
        delays=0.02/0.01/0.18/0.17, dsn=5.7.1, status=bounced (host[2607:f8b0:4003:c06::1b] said: 550-5.7.1 [2001:4800:7818:101:be76:4eff:fe05:3b20] \
        Our system has detected that 550-5.7.1 this message does not meet IPv6 sending guidelines regarding PTR 550-5.7.1 records and authentication. Please review 550-5.7.1  \ for more 550 5.7.1 information. b25si13682089otb.135 - gsmtp (in reply to end of DATA command)) 2
    Jul 29 13:18:45 alpha postfix/cleanup[12001]: 74E756228A: message-id=<>
    Jul 29 13:18:45 alpha postfix/qmgr[11112]: 74E756228A: from=<>, size=3057, nrcpt=1 (queue active)
    Jul 29 13:18:45 alpha postfix/bounce[12004]: 17BCE62284: sender non-delivery notification: 74E756228A  3
    Jul 29 13:18:45 alpha postfix/qmgr[11112]: 17BCE62284: removed4
    Jul 29 13:18:45 alpha postfix/local[12005]: 74E756228A: to=<>, relay=local, delay=0.02, delays=0/0.02/0/0, dsn=2.0.0, status=sent (delivered to mailbox)
    Jul 29 13:18:45 alpha postfix/qmgr[11112]: 74E756228A: removed 5
    root@alpha ~/


This line shows that the mail server successfully started, probably from a configuration reload. The timestamp shows that the restart was well before the message arrived.


This line shows the heart of the issue. By reading this line, there's not only a hint as to the problem, but also a link to the posted solution. Thank you very much, Google.


This line shows that it's a non-delivery notification - a "bounce".


The message is removed from the incoming queue.


The message, which is a delivery failure notice, has been delivered to the recipient's mailbox, and removed from all subsequent parts of the delivery system.

This sequence shows how a problem manifested because of a missing Reverse DNS Resource Record. This type of error is common, especially in the current trend of SPAM. All I had to do was follow the hints in the log entry to find the solution, which Google had posted. Listed below is the solution.

Figure 8.14. Add IPv6 Reverse Resource Record

Adding an IPv6 Reverse Resource Record.

The image above shows the resolution of the problem stated. In the Rackspace interface for the server, there's a setting for Reverse Record. This setting has two versions, one for IPv4, & one for IPv6. In the screenshot shown, a second Reverse Record was created for IPv6. It's an easy fix. Initially I only created the IPv4 Reverse Record. Once the setting is in place, it will take a few minutes for the information to propagate out.

SMTP Check Point Top of Page

Once you have your mail server correctly sending and receiving email, send me an email stating that it's configured and in place. I will send an email to the local user at your server. At that point, you can log in and Reply to the message that I sent to your server. Once I receive the reply, I will read the email headers to see if all the exchanges are correct and in place.

[32] In our case, port 25 is all that needs to be opened. When the email server is used on another port, that port will need to be open. Also, in some instances, receiving email may require that additional ports be open.

[33] The backslash (\) is a common element on the command line which sets the shell up to continue input on the next line.

[34] Check your Spam folder. You might go for quite a while thinking that Gmail isn't receiving mail, but it's being sent to the Spam folder instead.

[35] To completely open the firewall (flush out all the rules), issue the command `iptables -F`. To reload the firewall rules, issue the command `firewall-cmd --reload`. If you relax the firewall this way, make sure to put it back in place as soon as possible.