Sending and Receiving Electronic Mail - RHCE Section - RHCSA & RHCE Red Hat Enterprise Linux 7: Training and Exam Preparation Guide (EX200 and EX300), Third Edition (2015)

RHCSA & RHCE Red Hat Enterprise Linux 7: Training and Exam Preparation Guide (EX200 and EX300), Third Edition (2015)

Part II. RHCE Section

Chapter 23. Sending and Receiving Electronic Mail

This chapter describes the following major topics:

· Introduction to SMTP and electronic mail

· Overview of common terms and protocols

· How the mail system works

· Understand Postfix, its daemons, commands, configuration files, and log files

· Describe the use of various Postfix configuration files

· Review of SELinux requirements for Postfix operation

· Configure Postfix as a central mail server and test operation

· Set up Postfix as a relay host for local users and network users

RHCE Objectives:

79. Configure a system to forward all email to a central mail server

Email is the most widely used service on the Internet, and it is an effective, convenient, and easy-to-use communication tool that allows people to stay in touch with one another and share their thoughts and files electronically. Moreover, it is a productive messaging tool that every business relies on for instant, simultaneous communication with several people. The email system works similar to the way the traditional postal service operates. The primary protocol on which the entire email system stands is SMTP. There are numerous email server and client programs available, and several of them are supported in RHEL7 that can be configured on corporate networks for email exchange.

SMTP and the Email System

Simple Mail Transport Protocol (SMTP) is a networking protocol that is responsible for transporting email messages from one email server to another. It establishes a reliable connection between the source and the destination email server for message handover. This protocol runs on top of the IP protocol and uses well-known TCP port 25 for its operation. Using a combination of these protocols, a message is transported on the network or the Internet, passing through one or several routing devices to reach its ultimate identified destination.

An email message (just like an addressed envelope) typically has four parts: the sender’s ID and domain name, the receiver’s email address, a subject line, and a message body. The SMTP protocol uses the first two items to determine the sender and receiver’s domains, based on which it decides whether the message is destined for the local network. If the message is destined for the local network, the SMTP protocol delivers the message to the receiving user’s mailbox. If not, it sends the message across the Internet to the correct target system.

Common Terms

An operational email system typically performs four key functions: Mail User Agent (MUA), Mail Submission Agent (MUA), Mail Transport Agent (MTA), and Mail Delivery Agent (MDA). Some programs are designed to perform one of these functions only; however, most programs have the ability to do more than one. These four functions and other key components of the email system are described below.

Mail User Agent (MUA)

A Mail User Agent is an email client program used to compose messages, and to submit them to an outgoing MTA. On the receiving side, an MUA pulls the message into the inbox of the user and allows them to read. An MUA uses either the POP or IMAP protocol for mail retrieval. Some common MUAs are mail, mailx, mutt, evolution, pine, elm, thunderbird, and Outlook.

Mail Submission Agent (MSA)

A Mail Submission Agent is responsible for accepting new mail messages from an MUA. The MSA function may be integrated within an MUA or MTA, or it may be a separate program. It uses TCP port 587; however, it normally works on the SMTP port.

Mail Transport Agent (MTA)

A Mail Transport Agent is responsible for transporting a message from a sending mail server, and another MTA is responsible for accepting the message at a receiving mail server, and they both use SMTP. There may be more than one MTA involved before the message actually gets to the finaldestination. The most widely used MTA is sendmail; however, Postfix is a more popular alternative due to its simplicity and better performance. In RHEL7, sendmail is deprecated in favor of Postfix.

Mail Delivery Agent (MDA)

A Mail Delivery Agent is responsible for delivering an incoming message to a local mail spool location for storage. The MDA may be a separate program or its functionality may be integrated within an MTA. Examples of MDA are procmail and maildrop.

Post Office Protocol (POP)

The Post Office Protocol is used by an MUA and it is responsible for downloading user mail messages from the mail server to their local inboxes, and optionally, delete them on the server to free up space. This protocol proves to be more useful for users who use a single system to check their mail, or for those with intermittent Internet connections. The latest POP version is referred to as POP3, and it uses TCP port 110 for its operation. A secure cousin of POP3 is referred to as POP3s, which works on top of the SSL layer to provide secure authentication and data privacy. POP3s listens on TCP port 995.

Internet Message Access Protocol (IMAP)

The Internet Message Access Protocol is used by an MUA and it is responsible for downloading user mail messages from the mail server to their local inboxes. Unlike POP3, IMAP is more useful for users who use multiple systems to access their mail, and for those with slow Internet connections. The latest IMAP version is referred to as IMAP4, and it uses TCP port 143 for its operation. A secure cousin of IMAP4 is referred to as IMAPs, which works on top of the SSL layer to provide secure authentication and data privacy. IMAPs listens on TCP port 993.

Smart Host (Relay)

A smart host is an MTA that is configured with the intent to deliver email messages on behalf of other systems. The other systems may have non-persistent connection to the Internet or lack the capacity to perform this function efficiently.

Mail Queue

A mail queue is a directory location where submitted email messages are stored temporarily for further processing. The default mail queue for Postfix is located in the /var/spool/postfix directory.

Mailbox

A mailbox is a location for storing user email messages. By default, a mailbox file is created under the /var/spool/mail directory for each user account created on the system with a matching name.

How the Email System Works

A fully functional email system from a sender standpoint requires an email client (MUA) to compose an email message with all the relevant information, a program (MSA) that takes this email message and submits it to a temporary location (mail queue) for further processing, and another program (MTA) for transporting that email message over the network or the Internet to the destination system (another MTA) using the SMTP protocol. On the receiving side, the MTA receives that message and invokes an MDA, which forwards the message to a temporary mail spool location and holds it there until an MUA picks it up and saves it in the mailbox of the user via either POP3 or IMAP protocol. The mail server authenticates the user before allowing the MUA to access their email. See Figure 23-1 for a high-level process flow.

Images

Figure 23-1 Email – From Sender to Receiver

The flow of the email system from a sender to a receiver can be summarized as depicted in Figure 23-2.

MUA → MSA → MTA → Network / Internet → MTA → MDA → MUA

Figure 23-2 Email System Process

We can analogize the entire process of an email system to the traditional postal system for delivery of a letter (email message). From a sender perspective, a person (MUA) writes a letter and puts it in an envelope with a receiver’s name, destination address, and appropriate postage, and drops it at a mail facility. A postal worker (MSA) picks up the letter and takes it to a postal facility (mail queue) for culling, postmarking, scanning, barcoding, sorting, etc. After the processing is complete, the letter is transported (MTA) via a carrier (SMTP) to the delivery post office (another MTA) close to the destination address. A postal worker (MDA) gets the letter and delivers it to the mailbox of the receiver. The receiver (MUA) uses their mailbox key (authentication) to access the letter.

Depending on the location of the sending and receiving MUAs, the message may be transported across a large corporate network or over the Internet using several routing devices. In either case, DNS is employed for name resolution. For local delivery, the MTA simply places the message into the mailbox of the user for pickup by an MUA.

The remainder of this chapter covers Postfix at length; other tools mentioned earlier are beyond the scope.

Understanding Postfix

Postfix is sendmail compatible; however, it is easier to configure and administer, and it is more modular, more secure, and offers better performance. It includes features such as pattern matching for filtering unwanted mail, and support for setting up several virtual mail domains on a single system. Postfix is the default MTA used in RHEL7. It uses the SMTP protocol over port 25 for mail transfers. By default, Postfix, out of the box, is ready to accept mail from local system users.

Postfix Daemons

The primary service daemon for Postfix is the master daemon located in the /usr/libexec/postfix directory. This daemon process starts several agent processes, such as nqmgr, pickup, and smtpd, on demand to carry out tasks on its behalf. Each agent has a small, well-defined function and operates with the minimal privilege required for a successful execution of that function. The network queue manager agent, nqmgr, is responsible for mail transmission, relay, and local delivery, and the pickup agent transfers mail messages from the /var/spool/postfix directory to the /var/spool/mail directory in collaboration with the smtpd agent. These agent processes terminate after servicing clients or being inactive for a pre-determined period of time. The master and all agent processes work collaboratively to manage the entire Postfix email system.

Postfix Commands

Postfix offers several commands to administer the email system. These commands include Postfix-specific utilities, as well as general operating system tools, that are described in Table 23-1.

Command

Description

alternatives

Displays and sets the default MTA.

mail/mailx

Sends and receives email.

postalias/newaliases

Processes the aliases database, which is /etc/aliases by default.

postconf

Displays and modifies the Postfix configuration stored in the main.cf file.

postfix

Controls the operation of the Postfix service, including starting, stopping, health checking, and reloading the configuration.

postmap

Processes and converts some configuration files into Postfix-compatible databases.

postqueue/mailq

Lists and controls Postfix queue.

Table 23-1 Postfix and Other Mail Commands

Some of these commands are used later in this chapter. View the man pages for the rest for details and usage.

Postfix Configuration Files

Postfix configuration files are located in the /etc/postfix directory, with the exception of the aliases file, which is stored in /etc. A list of the configuration files can be viewed with the ll command:

image

Some essential configuration files are explained below.

The access File

The access file may be used to establish access control based on email addresses, or hosts, domains, or network addresses for Postfix use. The controls are placed in the form “pattern action”. Each pattern has an associated action, such as OK or REJECT. The following shows some examples.

To allow access to the specified IP address:

192.168.122.20 OK

To allow access to systems in the example.org domain:

example.com OK

To reject access to systems on the 192.168.3 network:

192.168.3 REJECT

The contents of this file are converted into an indexed database called access.db for Postfix use. After making changes to the access file, run the postmap command on the file to create or update the database:

# postmap /etc/postfix/access

# ll /etc/postfix/access*

-rw-r--r--. 1 root root 20876 Jan 26 2014 /etc/postfix/access

-rw-r--r--. 1 root root 12288 Feb 12 07:47 /etc/postfix/access.db

You can use firewalld as an alternative to using this database for host, domain, or network access control.

The canonical File

This optional file is used to establish mapping for local and non-local mail addresses. The mapping can be done on incoming mail from other users, domains, and networks, and it is configured in the form “pattern result”. The following shows some examples.

To forward mail sent to a local user user1 to user1@yahoo.com:

user1 user1@yahoo.com

To forward all mail destined for example.org domain to another domain example.com:

@example.org @example.com

The contents of this file are converted into an indexed database called canonical.db for Postfix use. After making changes to the canonical file, run the postmap command on the file to create or update the database:

image

The generic File

This optional file is used to establish mapping for local and non-local mail addresses throught outgoing mail. The syntax of this file is identical to that of the canonical file.

The contents of this file are converted into an indexed database called generic.db for Postfix use. After making changes to the generic file, run the postmap command on the file to create or update the database:

image

The main.cf File

The main.cf file is the primary Postfix configuration file, which defines global settings for its operation. These settings include the identification of the host, domain, origin, and destination to be served, the mail owner, the network interfaces to listen on, the name and location of the aliases database, the queue and user mailbox directory locations, and so on. Some key directives from this file are shown below in the order in which they appear in the main.cf file, and this order is important.

queue_directory

= /var/spool/postfix

command_directory

= /usr/sbin

daemon_directory

= /usr/libexec/postfix

mail_owner

= postfix

myhostname

= host2.example.com

mydomain

= example.com

myorigin

= $myhostname

inet_interfaces

= localhost

mydestination

= $myhostname, localhost.$mydomain, localhost

mynetworks

= 192.168.2.0/24, 127.0.0.0/8

relayhost

= $mydomain

alias_maps

= hash:/etc/aliases

alias_database

= hash:/etc/aliases

mail_spool_directory

= /var/spool/mail

These directives are explained in Table 23-2.

Directive

Description

queue_directory

Location of Postfix queue.

command_directory

Location of the Postfix commands.

daemon_directory

Location of the Postfix daemons.

mail_owner

Owner name for Postfix queue and daemons.

myhostname

FQDN of the Postfix server.

mydomain

Domain name of the Postfix server.

myorigin

Host or domain name the outgoing mail appears to have originated from.

inet_interfaces

Network interfaces to be used for incoming mail.

mydestination

Domains the Postfix server accepts mail from.

mynetworks

IP addresses of trusted networks.

relayhost

Hostname of another mail server (smart host) to forward mail to. This mail server will act as an outgoing mail gateway.

alias_maps

Aliases database used by local delivery agent.

aliases_database

Aliases database generated with the newaliases command.

mail_spool_directory

Location for storing user mailboxes.

Table 23-2 main.cf Directives

You can use the postconf command to display the default (–d) settings that are not defined in the file:

# postconf –d

bounce_notice_recipient = postmaster

access_map_defer_code = 450

access_map_reject_code = 554

address_verify_cache_cleanup_interval = 12h

address_verify_default_transport = $default_transport

address_verify_local_transport = $local_transport

address_verify_map = btree:$data_directory/verify_cache

address_verify_negative_cache = yes

…… . .

You can view the settings that are defined explicitly in the file using the postconf command with the –n switch:

# postconf –n

alias_database = hash:/etc/aliases

alias_maps = hash:/etc/aliases

command_directory = /usr/sbin

config_directory = /etc/postfix

daemon_directory = /usr/libexec/postfix

data_directory = /var/lib/postfix

debug_peer_level = 2

debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5

html_directory = no

inet_interfaces = localhost

inet_protocols = all

mail_owner = postfix

mailq_path = /usr/bin/mailq.postfix

manpage_directory = /usr/share/man

mydestination = $myhostname, localhost.$mydomain, localhost

newaliases_path = /usr/bin/newaliases.postfix

queue_directory = /var/spool/postfix

readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES

sample_directory = /usr/share/doc/postfix-2.10.1/samples

sendmail_path = /usr/sbin/sendmail.postfix

setgid_group = postdrop

unknown_local_recipient_reject_code = 550

Rather than editing the main.cf file manually for modifications, you can alter a directive value directly from the command prompt using the postconf command. For instance, the following sets the inet_interfaces directive to all:

# postconf –e inet_interfaces=all

Verify the change by greping for this directive in the file:

# grep ^inet_interfaces /etc/postfix/main.cf

Inet_interfaces = all

There is no need for the conversion of this file into a database as you did for the files discussed previously. Postfix reads this configuration file to obtain settings.

EXAM TIP: Understanding and use of mydomain, mydestination, myhostname, mynetworks, myorigin, inet_interfaces, and relayhost directives is important.

The master.cf File

The master.cf file defines configuration settings for the master daemon and the way it should interact with other service agents to achieve mail delivery. An excerpt from the file is provided below:

image

For each service listed in the first column, there are seven columns that define how the service is to be used. These columns are explained in Table 23-3.

Column

Description

service

Name of the service.

type

Transport mechanism to be used.

private

Whether the service is for Postfix use only.

unpriv

Whether the service is to be run by non-root users.

chroot

Whether the service is to be chrooted for the mail queue.

wakeup

Wake up interval for the service.

maxproc

Maximum number of threads the service can spawn.

command + args

Command associated with the service plus any arguments.

Table 23-3 master.cf File Description

There is no need to convert this file into a database. Postfix references this file for service agent settings.

The relocated File

This optional file contains information of users that have moved. This file is syntactically identical to the canonical and generic files. The following shows an example.

Assuming user1 has moved from example.com domain to example.net, you can forward all email received on their old address to a new one by adding the following line to the relocated file:

user1@example.com user1@example.net

The contents of this file are converted into an indexed database called relocated.db for Postfix use. After making changes to the relocated file, run the postmap command on the file to create or update the database:

image

The transport File

This optional file is used to establish mappings between email addresses and message delivery transports and next-hop destinations in the transport:nexthop format. An example of transport is local or smtp and that for nexthop a hostname or a domain name. For instance, the following entry sets up a mapping between a user email address and a host:

user1@example.com smtp:host1.example.com

The contents of this file are converted into an indexed database called transport.db for Postfix use. After making changes to the transport file, run the postmap command on the file to create or update the database:

image

The virtual File

This optional file may be used to redirect mail intended for one user to one or more other email addresses, or to implement a virtual alias domain with all email addresses aliased to addresses in other domains. The first example below redirects email for user1 to users root and user3, and the second example redirects email for user1 in the example.com domain to user root:

user1 root, user3

user1@example.com root

The contents of this file are converted into an indexed database called virtual.db for Postfix use. After making changes to the virtual file, run the postmap command on the file to create or update the database:

image

The /etc/aliases File

The /etc/aliases file delivers a mechanism to forward mail destined for local recipients to other local or remote addresses. Postfix references this file to determine alias settings. Some default contents from this file are displayed below:

image

The preceding output indicates that the root user receives messages generated by system users. You can set up something similar for other users too. For instance, if you wish to forward email for a deleted user account, user50, to a local user, user1, and a remote user, user2@host1.example.com, open the aliases file and add the following entry:

user50: user1, user2@host1.example.com

This file also allows you to create a mailing group with all members receiving the mail sent to the group. Here is how you would define a mailing group lnxadmteam with members user1, user2, and user3. Add the following line to the aliases file:

lnxadmteam: user1, user2, user3

After any modifications have been made to the aliases file, the Postfix service needs to be apprised. To this end, the contents of this file are converted into an indexed database called aliases.db by executing the newaliases command:

image

Postfix Logging

All mail messages and alerts are logged to the /var/log/maillog file, and are related to starting and stopping the Postfix service, successful and unsuccessful user connection attempts, mail sent and disallowed, warning messages, and so on. The maillog is a plain text file and may be viewed with any file viewing utility, such as head, tail, cat, more, or view. The following shows an excerpt from the file:

image

This log file grows over time depending on how busy the mail system is. The syslog service rotates this file once a week to prevent it from getting too large, and it saves previous four weeks of backup in the same directory.

EXAM TIP: You can open another terminal session on the system to run ‘tail –f’ on a log file.

Managing Postfix

Managing Postfix involves several configuration and administration tasks, including setting up Postfix as a network mail server and as a smart host, applying appropriate access controls, mapping email addresses, and creating aliases. These tasks are covered in exercises presented in this section.

SELinux Requirements for Postfix Operation

SELinux protects systems by setting appropriate controls using contexts and booleans. Before you proceed with the exercises, let’s look at the Postfix-specific SELinux contexts on processes, files, and port, and discuss the booleans that may need to be modified for Postfix to function properly. By default, all Postfix daemons, including master, pickup, and qmgr, run confined in their own domains and are labeled appropriately. For instance, the domain type associated with the master process is postfix_master_t, and that for pickup and qmgr are postfix_pickup_t and postfix_qmgr_t, respectively. This can be confirmed with the ps command as follows:

image

The SELinux file types associated with Postfix are postfix_exec_t on the /etc/postfix configuration directory, postfix_data_t on the /var/lib/postfix data directory, and postfix_spool_t on the /var/spool/postfix incoming and outgoing mail directory. Here is an ll command output that verifies this information:

image

The SELinux type associated with the SMTP port is smtp_port_t, and it is in place by default. Here is the semanage command output that validates this information:

# semanage port –l | grep smtp

smtp_port_t tcp 25, 465, 587

From a SELinux boolean perspective, there is a solo boolean that is associated with Postfix, and we can see this with the getsebool command:

# getsebool –a | grep postfix

postfix_local_write_mail_spool --> on

This boolean allows or disallows Postfix to write to the local mail spool on the system, and, by default, it is turned on.

By looking at the above SELinux settings for Postfix, we can establish that there are no changes required to make Postfix function smoothly in the SELinux enforcing mode.

Exercise 23-1: Configure a Central Mail Server

This exercise should be done on server1.

In this exercise, you will configure Postfix to serve systems on the local network (192.168.0.0/24). You will add server1 as the MTA in the example.com domain, listening on all network interfaces with DNS lookups disabled (disable_dns_lookups directive). You will check the Postfix configuration for any syntax errors, configure appropriate host-based access rules in firewalld, set Postfix to autostart at system reboots, start the Postfix service, and ensure that it is set as the default MTA. You will send an email to a local user user3 to ensure that the mail service is working for local users.

1. Install the Postfix software package:

# yum –y install postfix

Package 2:postfix-2.10.1-6.el7.x86_64 already installed and latest version

Nothing to do

2. Open the main.cf file in a text editor and set or modify the following directives. Leave other settings intact.

myhostname

= server1.example.com

mydomain

= example.com

myorigin

= $myhostname

inet_interfaces

= all

mydestination

= $myhostname, localhost.$mydomain, localhost, $mydomain

mynetworks

= 192.168.0.0/24, 127.0.0.0/8

disable_dns_lookups

= yes

ImagesThe default method for the mail system to resolve hostnames is DNS; however, in the absence of DNS service, you can instruct the mail system to use the hosts file instead by defining the disable_dns_lookups directive in the main.cf file and setting its value to yes.

3. Check for any syntax errors in the main.cf file using the postfix command:

# postfix check

4. Review the changes made in the main.cf file with the postconf command:

# postconf –n

alias_database

= hash:/etc/aliases

alias_maps

= hash:/etc/aliases

command_directory

= /usr/sbin

config_directory

= /etc/postfix

daemon_directory

= /usr/libexec/postfix

data_directory

= /var/lib/postfix

disable_dns_lookups

= yes

inet_interfaces

= all

inet_protocols

= all

mail_owner

= postfix

mail_spool_directory

= /var/spool/mail

mydestination

= $myhostname, localhost.$mydomain, localhost, $mydomain

mydomain

= example.com

myhostname

= server1.example.com

mynetworks

= 192.168.0.0/24, 127.0.0.0/8

myorigin

= $myhostname

queue_directory

= /var/spool/postfix

You may get additional lines in the output based on what was modified in the file.

5. Add the smtp service to firewalld persistently and reload the rules to allow traffic on SMTP port 25:

# firewall-cmd --permanent --add-service smtp; firewall-cmd --reload

6. Set Postfix to autostart at system reboots:

# systemctl enable postfix

ln -s '/usr/lib/systemd/system/postfix.service' '/etc/systemd/system/multi-user.target.wants/postfix.service'

7. Start the Postfix service and check its operational status:

# systemctl start postfix

# systemctl status postfix

postfix.service - Postfix Mail Transport Agent

Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled)

Active: active (running) since Thu 2015-02-12 17:44:13 EST; 3s ago

Process: 14879 ExecStop=/usr/sbin/postfix stop (code=exited, status=0/SUCCESS)

Process: 14893 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS)

Process: 14891 ExecStartPre=/usr/libexec/postfix/chroot-update (code=exited, status=0/SUCCESS)

Process: 14888 ExecStartPre=/usr/libexec/postfix/aliasesdb (code=exited, status=0/SUCCESS)

Main PID: 14965 (master)

CGroup: /system.slice/postfix.service

├─14965 /usr/libexec/postfix/master -w

├─14966 pickup -l -t unix -u

└─14967 qmgr -l -t unix -u

8. Configure Postfix as the default MTA using the alternatives command and verify:

# alternatives --set mta /usr/sbin/sendmail.postfix

# alternatives --display mta | grep current

link currently points to /usr/sbin/sendmail.postfix

9. Mail a message to user3 with the subject (–s) “Local Delivery Test” to test local mail delivery (the mail command is part of the mailx package, which needs to be installed if it is not already there):

# date | mail –s “Local Delivery Test” user3

10. Switch to user3 account and run the mail command to check whether this user has received the email. Press Enter at the & prompt to view the message and type q at the next & prompt to quit.

# su – user3

$ mail

Heirloom Mail version 12.5 7/5/10. Type ? for help.

"/var/spool/mail/user3": 1 message 1 new

>N 1 root Fri Feb 13 11:42 18/626 "Local Delivery Test"

&

Message 1:

From root@server1.example.com Fri Feb 13 11:42:50 2015

Return-Path: <root@server1.example.com>

X-Original-To: user3

Delivered-To: user3@server1.example.com

Date: Fri, 13 Feb 2015 11:42:50 -0500

To: user3@server1.example.com

Subject: Local Deliver Test

User-Agent: Heirloom mailx 12.5 7/5/10

Content-Type: text/plain; charset=us-ascii

From: root@server1.example.com (root)

Status: R

Fri Feb 13 11:42:50 EST 2015

& q

Held 1 message in /var/spool/mail/user3

You can tail the /var/log/maillog file to view messages generated during the implementation of this exercise.

This completes the procedure to set up a central mail server with Postfix.

EXAM TIP: By default, your email appears to have originated from server1.example.com. However, if you would like to change it to your domain name example.com, for instance, open main.cf and set myorigin directive to $mydomain. Save and quit the file, and restart Postfix. Try sending another test email and check the “From” line in the email.

Exercise 23-2: Test Central Mail Server from Remote Client

This exercise should be done on server2 (mail client) and server1 (mail server).

In this exercise, you will install the Postfix software package, modify it to avoid DNS lookups, enable Postfix, and start it. You will send an email to root on the mail server for verification. You will log on to server1 as user root and verify the receipt.

On server2 (mail client):

1. Install the Postfix software package:

# yum –y install postfix

2. Open the main.cf file in a text editor and add the following directive at the beginning of the file:

disable_dns_lookups = yes

3. Set Postfix to autostart at system reboots:

# systemctl enable postfix

4. Start the Postfix service:

# systemctl start postfix

5. Mail a message to root@server1.example.com with the subject “Remote Delivery Test” to test network mail delivery:

# date | mail –s “Remote Delivery Test” root@server1.example.com

On server1 (mail server):

6. Run the mail command to check whether the email has been received. Press Enter at the & prompt to view the message and type q at the next & prompt to quit. Install the mailx package to access the mail command if it is not already there.

# mail

Heirloom Mail version 12.5 7/5/10. Type ? for help.

"/var/spool/mail/root": 1 message 1 new

>N 1 root Fri Feb 13 11:46 21/854 "Remote Delivery Test"

&

Message 1:

From root@server2.example.com Fri Feb 13 11:46:00 2015

Return-Path: <root@server2.example.com>

X-Original-To: root@server1.example.com

Delivered-To: root@server1.example.com

Date: Sat, 14 Feb 2015 03:46:00 +1100

To: root@server1.example.com

Subject: Remote Delivery Test

User-Agent: Heirloom mailx 12.5 7/5/10

Content-Type: text/plain; charset=us-ascii

From: root@server2.example.com (root)

Status: R

Sat Feb 14 03:46:00 MIST 2015

& q

Held 1 message in /var/spool/mail/root

You can tail the /var/log/maillog file on both servers to view messages generated during the implementation of this exercise. Also, you can find the incoming mail for each user in the /var/spool/mail directory.

This completes the procedure for sending email from a remote system and receiving it on the mail server.

EXAM TIP: By default, your email appears to have originated from server2.example.com. However, if you would like to change it to your domain name example.com, for instance, open main.cf and set mydomain directive to example.com and myorigin directive to $mydomain. Save and quit the file, and restart Postfix. Try sending another test email and check the “From” line in the email.

Exercise 23-3: Configure Postfix to Forward Local Mail to a Central Mail Server and Reject Incoming Mail

This exercise should be done on host1 (mail client) and server1 (mail server).

In this exercise, you will install and configure Postfix on host1 to deny all incoming email (access control) and forward (relayhost) localhost mail to the central mail server (server1). You will disable the use of DNS for lookups. You will ensure that any mail received on the central mail server appears to have originated from example.com and not host1.example.com. You will check the Postfix configuration for any syntax errors, configure appropriate host-based access rules in firewalld, set Postfix to autostart at system reboots, start the Postfix service, and ensure that it is set as the default MTA. You will send an email to a local user user1 on host1 and confirm its receipt on the mail server.

On host1 (mail client):

1. Install the postfix software package:

# yum –y install postfix

Package 2:postfix-2.10.1-6.el7.x86_64 already installed and latest version

Nothing to do

2. Open the main.cf file in a text editor and set or modify the following directives. Leave other settings intact.

myhostname

= host1.example.com

mydomain

= example.com

myorigin

= $mydomain

inet_interfaces

= localhost

mydestination

= localhost

relayhost

= server1.example.com

disable_dns_lookups

= yes

3. Check for any syntax errors in the main.cf file using the postfix command:

# postfix check

4. Review the changes made in the main.cf file with the postconf command:

# postconf –n

command_directory

= /usr/sbin

config_directory

= /etc/postfix

daemon_directory

= /usr/libexec/postfix

data_directory

= /var/lib/postfix

disable_dns_lookups

= yes

inet_interfaces

= localhost

mail_owner

= postfix

mydestination

= localhost

mydomain

= example.com

myhostname

= host1.example.com

myorigin

= $mydomain

queue_directory

= /var/spool/postfix

relayhost

= server1.example.com

You may get additional lines in the output based on what was modified in the file.

5. Add the smtp service to firewalld persistently and reload the rules to allow traffic on SMTP port 25:

# firewall-cmd --permanent --add-service smtp; firewall-cmd --reload

6. Set Postfix to autostart at system reboots:

# systemctl enable postfix

ln -s '/usr/lib/systemd/system/postfix.service' '/etc/systemd/system/multi-user.target.wants/postfix.service'

7. Start the Postfix service and check its operational status:

# systemctl start postfix

8. Configure Postfix as the default MTA using the alternatives command, and verify:

# alternatives --set mta /usr/sbin/sendmail.postfix

# alternatives --display mta | grep current

link currently points to /usr/sbin/sendmail.postfix

9. Mail a message to user1 (this account should exist on both host1 and server1) with the subject (–s) “Relay Host Delivery Test” to test the relay host functionality:

# date | mail –s “Relay Host Delivery Test” user1

On server1 (mail server):

10. Log on to server1 as user user1, and run the mail command to check whether this user has received the email. Press Enter at the & prompt to view the message and type q at the next & prompt to quit.

$ mail

Heirloom Mail version 12.5 7/5/10. Type ? for help.

"/var/spool/mail/user1": 1 message 1 new

>N 1 root Thu Feb 12 19:11 20/781 "Relay Host Delivery Test"

&

Message 1:

From root@example.com Thu Feb 12 19:11:12 2015

Return-Path: <root@example.com>

X-Original-To: user1

Delivered-To: user1@server1.example.com

Date: Thu, 12 Feb 2015 19:11:12 -0500

To: user1@server1.example.com

Subject: Relay Host Delivery Test

User-Agent: Heirloom mailx 12.5 7/5/10

Content-Type: text/plain; charset=us-ascii

From: root@example.com (root)

Status: R

Thu Feb 12 19:11:12 EST 2015

& q

Held 1 message in /var/spool/mail/user1

You can tail the /var/log/maillog file on both servers to view messages generated during the implementation of this exercise. In addition, you can find the incoming mail for each user in the /var/spool/mail directory.

This completes the procedure to set up and test a relay host for localhost only.

Exercise 23-4: Configure Postfix to Receive Local Network Mail and Forward All Mail to a Central Mail Server

This exercise involves host1 (relay host), server1 (mail server), and server2 (mail client).

In this exercise, you will extend the ability of the mail client configured on host1 to accept all incoming email and forward both local and incoming mail to the central mail server (server1). The rest of the configuration will stay the same. You will submit an email on server2 touser1@host1.example.com and it should be received by user1 on the mail server.

On host1 (relay host):

1. Open the main.cf file in a text editor and set or modify the following directives. Leave other settings intact.

myhostname

= host1.example.com

mydomain

= example.com

myorigin

= $mydomain

inet_interfaces

= all

mydestination

= $myhostname, localhost.$mydomain, localhost, $mydomain

mynetworks

= 192.168.0.0/24, 127.0.0.0/8

relayhost

= server1.example.com

disable_dns_lookups

= yes

2. Restart the Postfix service:

# systemctl restart postfix

On server2 (mail client):

3. Mail a message to user1@host1.example.com with the subject (–s) “Relay Host Delivery Test Exercise 23-4” to test the relay host functionality from a network system:

# date | mail –s “Relay Host Delivery Test Exercise 23-4” user1@host1.example.com

On server1 (mail server):

4. Log on to server1 as user1 and run the mail command to check whether this user has received the email. Press Enter at the & prompt to view the message and type q at the next & prompt to quit.

$ mail

"/var/spool/mail/user1": 1 message 1 new

>N 1 root Thu Feb 13 20:23 23/878 "Relay Host Delivery Test Exercise 23-4"

& q

Held 1 message in /var/spool/mail/user1

You can tail the /var/log/maillog file on host1 and server1 to view messages generated during the testing.

This completes the procedure to set up and test a relay host for network systems.

Chapter Summary

This chapter presented an introduction to email service and provided several exercises to practice the implementation. The chapter examined the SMTP protocol and described common terms and protocols that are part of the email system. It described how the email system works and analogized it to the traditional postal system. It discussed Postfix daemons and commands, analyzed various required and optional configuration files, and discussed SELinux file, process, and port contexts, as well as booleans. The chapter demonstrated the configuration of a central mail server for the network, relayhosts for local and network use, and how to test them.

Chapter Review Questions

1. What is the use of the mydestination directive?

2. What is the name of the Postfix access control file?

3. Evolution is an example of an MTA. True or False?

4. What functionality does an MTA provide?

5. What is the default myorigin directive setting?

6. The mail command may be used to verify the functionality of a mail server. True or False?

7. Directives in the main.cf file can be modified directly from the command line. What command is used for this purpose?

8. Which file does Postfix use to log mail alerts?

9. Which Postfix command is used to convert text configuration files into indexed databases?

10. Which file controls the behavior of Postfix daemons and agents?

11. Where are the Postfix configuration files located?

12. An MUA is responsible to transport email messages over the network. True or False?

13. What is the equivalent Postfix command for mailq?

14. What command would you use to display or alter the current MTA?

15. Why do we use the disable_dns_lookups directive?

16. What protocol and port does the mail system use?

17. What would the command postconf –n do?

18. What is the purpose of the relayhost directive?

19. What two protocols are used to pull user mail in to their inboxes?

20. What would the entry “example.com REJECT” in the access file imply?

21. How do you notify Postfix service of a change in the /etc/aliases file?

22. When should you run the postfix check command?

23. Which file defines mapping for email addresses?

24. The access file can be used to allow or disallow a host, domain, or network from accessing the Postfix service. True or False?

25. Which command would you run to update the aliases database?

26. What would the command postconf –e setgid_group=postdrop do?

27. What is the name of the main daemon for the Postfix service?

28. By default, all Postfix daemons and agents run in their own SELinux domains. True or False?

Answers to Chapter Review Questions

1. The mydestination directive defines the hosts and domains that the mail server is configured to serve.

2. The name of the Postfix access control file is access.

3. False. Evolution is an MUA program.

4. An MTA is responsible for transporting email messages between mail servers.

5. The default myorigin directive is set to $myhostname.

6. False. The mail command is used to read and compose email messages.

7. The postconf command can be used to modify directives in the main.cf file directly from the command prompt.

8. Postfix uses the /var/log/maillog file for logging.

9. The postmap command is used to convert configuration files into indexed databases.

10. The master.cf file controls the behavior of Postfix daemons and agents.

11. The Postfix configuration files are located in the /etc/postfix directory.

12. False. An MUA is used to read and compose email messages.

13. The equivalent command is postqueue with the –p switch.

14. The alternatives command is used to display and alter the current MTA setting.

15. The disable_dns_lookups is used to enable or disable the use of DNS lookups.

16. The mail system uses the SMTP protocol on well-known port 25.

17. This command displays non-default Postfix settings.

18. The relayhost directive specifies the mail server to forward mail to.

19. POP3 and IMAP protocols are used to pull user mail messages into their inboxes.

20. This entry would reject incoming mail from systems in the example.com domain.

21. By executing the newaliases command.

22. After making changes to the main.cf file for syntax errors.

23. In the /etc/aliases file.

24. True.

25. The newaliases command is run after making edits in the aliases file.

26. This command will modify the directive’s value in the main.cf file without having to open the file in a text editor.

27. The main daemon for the Postfix service is called master.

28. True.

DIY Challenge Labs

The following labs are useful to strengthen the concepts and topics learned in this chapter. It is expected that you perform these labs without any additional help. A step-by-step guide is not provided, as the implementation of these labs requires the knowledge that has been presented in this chapter. Use defaults or your own thinking for missing information.

Lab 23-1: Establish a Network Mail Server and Test It

Establish a RHEL7 system as a network mail server for network 192.168.1.0/24. This server should reject inbound mail from 192.168.0.0/24 and example.org. Create a mapping in the appropriate file to forward mail destined for user1 and group dba to user3. On the client, ensure that outbound mail appears to originate from example.com domain.

Lab 23-2: Establish a Forwarding Mail Server and Test It

Configure a RHEL7 system to relay localhost as well as all inbound mail to the central mail server set up in the previous lab. On the client, ensure that outbound mail appears to originate from example.net domain.