Chapter 8. SMTP

Table of Contents

Postfix Mail Service Introduction
Postfix Installation
SMTP Configuration
SMTP Logs
SMTP Firewall
Testing & Troubleshooting Email
SMTP Check Point

Postfix Mail Service Introduction

In this chapter, we will configure the email system. By default, CentOS and Red Hat now use the Postfix email service. The "out of the box" installation of Postfix is close to workable. There are six 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 DNSBL.info 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

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.

SMTP Configuration

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 'main.cf', 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 talos-iv.net with <your-domain-name>. 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.

Figure 8.6. Postfix Restart

Postfix Restart

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

Figure 8.7. Postfix MX Record Image #1

Postfix MX Record Image #1

The image above shows the DNS utility within the RackSpace interface. We need to create an entry for the MX (Mail eXchange) record, which points to our machine. [27]

Figure 8.8. Postfix MX Record Image #2

Postfix MX Record Image #2

Once configured, there should be several DNS records for our machine, accumulated throughout this course, as indicated.

SMTP Logs

The mail logs are our best friends when it comes to troubleshooting mail delivery. The images below give an overview of what we're dealing with. The the section called "Testing & Troubleshooting Email" below gives step-by-step instructions on how to dig into these logs.

Figure 8.9. 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.10. Postfix Check Image #4

Postfix Check Image #4

This image gives a preview of entries in a maillog. There is a wealth of information logged on each line.

SMTP Firewall

Configuring the IPTables 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.11. Postfix Firewall Image #1

Postfix Firewall Image #1

This first images shows that we have several ports open from previous exercises. However, as indicated, port 25 is not open. Therefore, at this time, email cannot be received by this machine from external sources. The output above was returned by the command `iptables -vnL`.[28]

Figure 8.12. Postfix Firewall Image #2

Postfix Firewall Image #2

First, we start the configuration by issuing the command `system-config-firewall-tui`.

Figure 8.13. Postfix Firewall Image #3

Postfix Firewall Image #3

We want the firewall Enabled. TAB through to Customize, and hit ENTER.

Figure 8.14. Postfix Firewall Image #4

Postfix Firewall Image #4

Scroll down to Mail (SMTP), and enable the option by pressing the SPACE bar. Then TAB through to Close, and press ENTER.

Figure 8.15. Postfix Firewall Image #5

Postfix Firewall Image #5

TAB through to OK, and press ENTER.

Figure 8.16. Postfix Firewall Image #6

Postfix Firewall Image #6

TAB through to Yes, and press ENTER.

Figure 8.17. Postfix Firewall Image #7

Postfix Firewall Image #7

Finally, as indicated, port 25 is now open. The output above was returned by the command `iptables -vnL`.

Testing & Troubleshooting Email

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. Please bear in mind the following steps:

  1. To test mail delivery and receipt, it helps to have access to two servers and the log files of both machines.[29]
  2. The first thing to verify is whether the machine being configured can send email out. Gmail helped with this step.[30]
  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. If email works with the firewall down, the problem is with the firewall configuration.

Figure 8.18. postfix Check Image #1

postfix Check Image #1

The above image shows successful installation of the mailx utility.

Figure 8.19. Postfix Check Image #2

Postfix Check Image #2

This image shows the mailx utility in action. When you are finished typing the message, press CTRL + D and mailx will send the message and display EOT.


    Aug  9 21:52:11 alpha postfix/smtpd[6320]: connect from mail-wi0-f173.google.com[209.85.212.173] 1
    Aug  9 21:52:12 alpha postfix/smtpd[6320]: 0905C13E151: client=mail-wi0-f173.google.com[209.85.212.173] 2
    Aug  9 21:52:12 alpha postfix/cleanup[6324]: 0905C13E151: message-id=<CAMZpurOAVKb4m6-pVObYTzo0oBwHXp6eqQKpMLE61Yqq3BV22Q@mail.gmail.com> 3 
    Aug  9 21:52:12 alpha postfix/qmgr[6317]: 0905C13E151: from=<bob.carnaghi@gmail.com>, size=2292, nrcpt=1 (queue active) 4 
    Aug  9 21:52:12 alpha postfix/local[6325]: 0905C13E151: to=<bob@talos-iv.net>, 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 mail-wi0-f173.google.com[209.85.212.173] 7

1

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

2

The Google mail server has identified itself.

3

The unique ID of the mail message is stated.

4

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

5

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.

6

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

7

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.

[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.


 
    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=<20140809215348.GA6378@alpha.talos-iv.net> 2
    Aug  9 21:53:48 alpha postfix/qmgr[6317]: 93BF413E152: from=<bob@talos-iv.net>, size=927, nrcpt=1 (queue active) 3
    Aug  9 21:53:49 alpha postfix/smtp[6448]: 93BF413E152: to=<bob.carnaghi@gmail.com>, relay=gmail-smtp-in.l.google.com[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

1

The message is coming from the local Linux user bob.

2

The unique message ID number is stated.

3

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

4

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.

5

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.


 
    Aug  9 16:13:22 alpha postfix/qmgr[13271]: 5A5EA13E3E9: from=<bob@blue-meltdown.net>, size=1107, nrcpt=1 (queue active) 1
    Aug  9 16:13:58 alpha amavis[23336]: (23336-10) Passed CLEAN {RelayedOpenRelay}, [50.56.249.136]:40896 [50.56.249.136] 
         <bob@blue-meltdown.net> -> <bob@talos-iv.net>, Message-ID: <alpine.LRH.2.11.1408091612100.17472@alpha.blue-meltdown.net>, \
         mail_id: pAv-mGC5J9S9, Hits: -1.9, size: 1107, queued_as: 9114613E3EA, 36168 ms 2
    Aug  9 16:13:58 alpha postfix/qmgr[13271]: 9114613E3EA: from=<bob@blue-meltdown.net>, size=1560, nrcpt=1 (queue active) 3 
    Aug  9 16:13:58 alpha postfix/lmtp[17609]: 5A5EA13E3E9: to=<bob@talos-iv.net>, relay=127.0.0.1[127.0.0.1]:10024, \
         delay=37, delays=0.22/0.1/0.01/36, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 9114613E3EA) 4 
    Aug  9 16:13:59 alpha postfix/smtp[17671]: 9114613E3EA: to=<bob@talos-iv.net>, relay=none, delay=0.76, delays=0.52/0.1/0.14/0, \
         dsn=4.4.1, status=deferred (connect to alpha.talos-iv.net[67.207.157.187]:25: Connection refused) 5

1

The message is currently in the queue.

2

This line shows the amavis service at work. The message has been scanned by SpamAssassin, and the "Hits" value shows that it isn't rated as Spam. Note also that the message is stated to come from alpine, which is a command-line email client. Note also the time differential from the line above. Something went on in the server for about 36 seconds between logging of these messages.

3

The message is in the send queue.

4

The message has been transferred from the send queue to localhost for relay.

5

This line shows status=deferred, and a failure of Connection refused. This means that the receiving email server would not permit the connection.

The exchange above shows an email that is being sent from the server alpha.blue-meltdown.net to alpha.talos-iv.net. Note that the final status of the delivery is failure due to the fact that alpha.talos-iv.net will not permit the connection for delivery. Having access to the log files of both servers permits this type of fine-grained troubleshooting to pinpoint the failures.


 
    Aug  9 16:10:37 alpha amavis[27046]: (27046-11) Passed CLEAN {RelayedInbound}, [67.207.157.187]:51200 [67.207.157.187] \
         <bob@alpha.talos-iv.net> -> <bob@blue-meltdown.net>, Message-ID: <20140809210946.GA3298@alpha.talos-iv.net>, \
         mail_id: rnnw3-6bcXle, Hits: 0.676, size: 654, queued_as: 8A96A13E3EA, 40511 ms 1
    Aug  9 16:10:37 alpha postfix/qmgr[13271]: 8A96A13E3EA: from=<bob@alpha.talos-iv.net>, size=1117, nrcpt=1 (queue active) 2 
    Aug  9 16:10:37 alpha postfix/lmtp[17392]: 03F3D13E3E9: to=<bob@blue-meltdown.net>, relay=127.0.0.1[127.0.0.1]:10024, \
         delay=41, delays=0.22/0.02/0.01/41, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8A96A13E3EA) 3 
    Aug  9 16:10:38 alpha postfix/local[17406]: 8A96A13E3EA: to=<bob@blue-meltdown.net>, relay=local, delay=0.76, \
         delays=0.38/0.22/0/0.16, dsn=2.0.0, status=sent (delivered to mailbox) 4

1

The incoming message has cleared the incoming Spam filters.

2

The message is sent to the queue to await delivery.

3

The message is relayed locally between the queue manager and localhost.

4

The message is sent to the local user's mailbox.

The exchange above shows a message being received by alpha.blue-meltdown.net from alpha.talos-iv.net. Note that, after the sequence of events, it is successfully (status=sent) delivered to the local user's mailbox.


 
    Aug  9 16:22:08 alpha amavis[27046]: (27046-12) Passed CLEAN {RelayedOpenRelay}, [50.56.249.136]:40901 [50.56.249.136] \
         <bob@blue-meltdown.net> -> <bob@alpha.talos-iv.net>, Message-ID: <alpine.LRH.2.11.1408091621010.18110@alpha.blue-meltdown.net>, \
         mail_id: KNva6DtJWSGo, Hits: -1.9, size: 1086, queued_as: 02D8A13E3EB, 32523 ms 1
    Aug  9 16:22:08 alpha postfix/qmgr[13271]: 02D8A13E3EB: from=<bob@blue-meltdown.net>, size=1551, nrcpt=1 (queue active) 2 
    Aug  9 16:22:08 alpha postfix/lmtp[18124]: 6028213E3E9: to=<bob@alpha.talos-iv.net>, relay=127.0.0.1[127.0.0.1]:10024, delay=33, \
         delays=0.14/0.03/0.01/33, dsn=2.0.0, status=sent (250 2.0.0 from MTA(smtp:[127.0.0.1]:10025): 250 2.0.0 Ok: queued as 02D8A13E3EB) 3
    Aug  9 16:22:08 alpha postfix/smtp[18182]: 02D8A13E3EB: to=<bob@alpha.talos-iv.net>, relay=none, 
         delay=0.39, delays=0.15/0.04/0.2/0, dsn=4.4.1, status=deferred (connect to alpha.talos-iv.net[67.207.157.187]:25: Connection refused) 4

1

The outgoing message clears the local amavis service that performs SpamAssassin and other tests on the message.

2

The message is placed into the mail queue to await delivery.

3

The message is passed from the queue to localhost for delivery by Postfix.

4

The message fails to be delivered, once again due to a connection error.

The above exchange once again shows a message that is being delivered from the machine alpha.blue-meltdown.net to alpha.talos-iv.net. The messages goes through the usual steps and shows a final status=deferred due to a connection error. From this error, I know that postifx is not configured correctly on alpha.talos-iv.net.

SMTP Check Point

Once you have your mail server correctly sending and receiving email, send me an email stating that it's in place. I will send an email to 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.



[27] NOTE that it may be necessary to add an MX record for the domain (talos-iv.net) only instead of for the machine (alpha.talos-iv.net). Some instances have required this, and some have not.

[28] 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.

[29] During the setup and testing of the configuration outlined in this chapter, I had access to two machines. This gave me access to the log files of both machines so I could see exactly what failed where and when. I also used my Gmail account.

[30] Watch 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.