Lab08Email

Information Sciences and
Technology Department
Network Services – Fall 2151
Lab 8 – Email Server
INTRODUCTION
Email is one of the most ubiquitous services in an enterprise network and it is the most visible to all
levels within an organization, from the CEO right down to the lowly IT helpdesk personnel. This lab will
give you a deeper understanding of the steps involved in an email transaction, the role a client takes,
as well as the applications involved and how the email server handles the messages it receives. The
various protocols used include IMAP, SMTP and POP3. This lab will focus on the two most common
protocols used to transmit messages from the client to the mail server, and from the mail server to
the client, SMTP and IMAP.
This lab will have three core parts; first the addition of a CentOS 7 email server to your existing
environment that will require two software packages, Postfix and Dovecot. Postfix will be the mail
transport agent using the SMTP protocol and Dovecot will be the mail delivery agent using IMAP. This
device will be collectively referred to during the instructions as the “mail server”, specifically for many
of the examples provided in these instructions it will be referred to as “mail.fruit.com”. Then you will
use a client machine to act as the mail user agent, the examples used in these instructions use
Thunderbird for the MUA, however you are free to use any client software you wish.
You will also be introduced to SSL (Secure Sockets Layer) and TLS (Transport Layer Security). These
protocols are designed to secure network transmissions through encryption. During this lab you will
configure SSL for SMTP and IMAP, but if you want to learn more about the protocols in general, I
recommend reading the “SSL and TLS: A Beginners Guide” published by the SANS Institute. This
document is posted to myCourses. You will also get a brief introduction to PAM (Pluggable
Authentication Module). PAM is used to centralize network and local authentication on Linux
systems. If you’d like to learn more about PAM, the Linux-PAM System Administrators' Guideis an
excellent resource (also available in myCourses).
SUMMARY
1. INITIAL NETWORK SETUP
1.1. BASIC NETWORK SETUP
1.2. SOFTWARE INSTALLATION
1.3. SYSTEM PREREQUISITES
Arcoraci/Klebes Page 1of 18

2. SSL CONFIGURATION
2.1. CERTIFICATE AND KEY CREATION
2.2. SUBMITTING THE CERTIFICATE SIGNING REQUEST
3. CONFIGURE CENTOS 7 AS MTA (POSTFIX)
3.1. CREATE NEW MAIN.CF
3.2. MODIFY MASTER.CF
3.3. TEST SMTP VIA TELNET
4. CONFIGURE CENTOS 7 AS MDA (DOVECOT)
4.1. RECREATE DOVECOT.CONF
4.2. EDIT /ETC/PAM.D/DOVECOT
4.3. TEST IMAP VIA TELNET
5. CONFIGURE CENTOS 7 AS MTA (THUNDERBIRD)
5.1. CONFIGURE THUNDERBIRD
5.2. TEST FUNCTIONALITY
Keep an eye open for the pencilicon, it means you need a sign off!
ACTIVITIES
1. INITIAL NETWORK SETUP
1.1. BASIC NETWORK SETUP
For this lab you will be using two CentOS 7 virtual machines, DNS will need to be working and it’s
recommended you use your primary DNS as the email server. You will also need to include another
CentOS VM to be used as the client.
1.2. SOFTWARE INSTALLATION
You will also need to install software on these devices and may need to switch to a “bridged” or
“NAT” connection and use RITs’ DNS server (129.21.3.17) temporarily to do this.
The following software needs to be installed:
● On the email server install the Telnet service (for local testing), Postfix and Dovecot.
● On the client install the Telnet service (for possible troubleshooting) and Thunderbird.
You should be pretty familiar with installing software using the yumcommand, but if you need a
refresher the Red Hat Enterprise 7 System Administrator Guideis a good resource. Other resources
you may find useful for this lab include the following links.

● http://www.dovecot.org
● http://www.postfix.org/
1.3. LAB PREREQUISITES
Once, you have the required software installed and your devices are updated, verify DNS resolution
and local network connectivity, you will need DNS to work! You will want to use your primary DNS
server from the previous lab and use another CentOS 7 VM as a client. Once the devices are set up,
perform the usual tests to make sure they can communicate with each other.
Verification Checklist
◻ Both the CentOS 7 Email Server and client can resolve DNS
◻ Firewalld is disabled on all Linux devices
◻ SELinux is set to permissive mode on all Linux Devices
◻ All devices on the Local LAN can “ping” each other
◻ Make sure both Linux devices are fully updated
◻ Add the MX resource record to the forward lookup zone data file for the zone
Finally, create a user for testing. Throughout these instructions I will be using Mary Poppins
(mpoppins) for the email test account.
2. SSL CONFIGURATION
In order to secure our email transmissions using SSL, we’ll want to encrypt the communication using a
self-signed certificate and key. OpenSSL is installed by default on CentOS 7; if you want to check the
version, type the command yum info openssl, if it is installed, it will return information similar to
figure 1. While creating the certificates is not overly complicated it does involve additional
configuration of the server and associated software. Keep this in mind and make note of the location
of the certificate and key. You may need to create the “private” directory using the mkdircommand
(this directory should only be readable by root, as it will contain private keys).

Figure 1– OpenSSL Information
2.1. CREATING THE KEY AND SELF SIGNED CERTIFICATE
To create the keyand certificatetype the following command as a single linein the CLI (it is a good
practice to use the FQDN as the file name, such as mail.fruit.com.key and mail.fruit.com.pem,
respectively, to easily identify what URL a key/cert pair is associated with).

openssl req x509 nodes days 365 newkey rsa:2048 keyout
/etc/ssl/private/mail.key out /etc/ssl/certs/mailcert.pem

Note 1:This key is private and should only be readable by root. Notice the location of the certificate,
/etc/ssl/certs/mailcert.pem and the key, /etc/ssl/private/mail.key.
Note 2: It’s important you use the mail server’s fully-qualified domain name (FQDN) in the Common
Name (CN) block. Most applications will show warnings, errors, or even refuse to allow access to the
site if the FQDN visited does not match the CN of the certificate returned.
2.2. GENERATING THE CERTIFICATE SIGNING REQUEST (CSR)
In a production environment, you will need to create a Certificate Signing Request (CSR). The CSR
contains information about your organization and the site the certificate will be used for, and is
submitted to a Certification Authority (CA), such as VeriSign, for signing. To create a CSR,type the

following command as a single linein the CLI (for the purposes of this lab, a self-signed certificate,
such as the mailcert.pem created in step 2.1, is sufficient).

openssl req nodes days 365 newkey rsa:2048 key /etc/ssl/private/mail.key
out mailcert.csr
3. CONFIGURE CENTOS 7 AS THE MTA (POSTFIX)
For this activity we need to configure Postfix. Postfix will be responsible for receiving emails from the
client to be forwarded to the mail delivery agent. You will need to edit two Postfix configuration files.
It is highly recommended that for the main.cfand master.cfconfiguration files you make copies of the
originals; we will edit the existing master.cf and create main.cf from a clean slate. There are many
configuration settings that impact other settings within Postfix and it will be much easier to keep track
of your configuration settings with a new file. The main.cf file contains 679 lines of code, most of
which we do not need to concern ourselves with, however there is plenty of information about what
those settings do, so make a copy for reference.
3.1. CREATE NEW MAIN.CONF
First, make a copy of main.cf and call it main.cf.bck. Referring to figure 2 you can easily see why
creating a new file is preferable to editing the original, all you need to do is add roughly 20 lines of
code (Figure 2).

Figure 2- Sample main.cf configuration settings
Referring to figure 2, let’s cover some of the important Postfix configuration parameters. It should be
obvious, but it’s worth noting that many of the configuration settings involve DNS (Figure 2, 1).
Notice the mydomain, myhostname, and myorigin parameters; these are used to tell other email
servers and the recipient information about where the email originated. In the example, the
“myorigin” parameter creates the source email address of the message; when the user Mary Poppins
(mpoppins) sends an email, the recipient will see that it came from mpoppins@fruit.com, defined by
the “myhostname” and “mydomain” parameters.
Referring to figure 2, 2; these parameters provide information about the network. In the example,
since we are only using the local interface for testing, the loopback is used for the parameter
“mynetworks”. To illustrate the configuration setting for an actual network, I’ve commented the
statement “#mynetworks = 192.168.1.0/24”, if this was being used it would define a space-separated
list of networks that are allowed to relay. In this lab we are only testing email within our local
network so it is not needed. Finally, the “inet_interface” parameter, defines the interfaces on which
the Postfix service will offer SMTP. By default, it is set to the loopback only, since our device is only
listening on one interface set it to “all”. In the real world you would want to define specific interfaces
to reduce your exposure to attacks.
Next you notice many Postfix parameters used to configure SSL and certificate settings (Figure 2, 3).
Early in the lab you were told to be mindful of the location of the key and the certificate locations,
here you should notice the two parameters used to identify the location of these items,
“smptd_tls_cert_file” and ”smtpd_tls_key_file”. If you are interested in learning more about the

other settings visit www.postfix.organd refer to the section on “SMTP Server specific settings”, and
click the link “Server-side certificate and private key configuration”. This section provides details
regarding all available configuration settings and their purpose. I’ve included the link for your
convenience.
http://www.postfix.org/TLS_README.html#server_tls
To check for errors related to any of the configuration Postfix parameters use the postconf
command. If you use it without any argument it will check all 816 configuration parameters in the
original main.cf file, if you created the file from scratch (hopefully you did) then it still check all the
settings; try it. It should also be noted that you can modify these settings using the “-e” switch
followed by the setting you want to change. For example, if I were type postconf mydomain, based
on the example provided it would return “mydomain = fruit.com” and postconf e
mydomain=foo.barwould change it to “foo.bar”
For the report, you will need a screenshot of your working Postfix configuration file.
3.2. MODIFY MASTER.CF
For this activity you will be editing the master.cffile. You don’t need to make many changes to this
file and these instructions have you editing it, nevertheless as a precaution it’s recommended you
make a backup. First, uncomment the lines beginning with smtp and submission, as indicated by
number 1 in figure 3. Un-comment, modify, and add all the “-o” lines identified in figure 3, number 2.
Follow figure 3 closely, only making changes necessary for your configuration. These lines of code are
related to the smtpd process and security settings used by Postfix. If you’re interested in the details,
the file has plenty of information included in the comments and you can also find more information in
the Postfix master (5) manual page. There is also plenty of information on how to debug problems
using the following link, http://www.postfix.org/DEBUG_README.html.

Figure 3– sample master.cf configuration settings
3.3. TEST SMTP VIA OPENSSL’S S_CLIENT
Once Postfix is configured we need to test its functionality locally, to do this we’ll use the s_client
from OpenSSL and SMTP commands. This program allows us to get a rudimentary interactive session
with, as well as confirm the certificate information of, a server using SSL or TLS. The following steps
illustrate a successful connection.
1. Let’s connect to the SMTP service by issuing the following command, using your domain
name.
openssl s_client starttls smtp crlf connect mail.fruit.com:25
2. This will generate a response containing first the certificate information and TLS session ticket,
then drop us into an interactive shell.
250 DSN
3. Next type, helo fruit.com. This will return the following response from the server.
250mail.fruit.com
4. Next type the command, mail from: mpoppins@fruit.com, where mpoppins is the local
user. This will return the following response.
250 2.1.0 Ok

5. Next type the command rcpt to: mpoppins@fruit.com, where mpoppins is your local
user account. This will return the following response.
250 2.1.5 Ok
6. Next type the command data, and this will return the following.
354 End data with <CR><LF>.<CR><LF>
7. Now type whatever you would like in the body of the email message. When you are done,
type the “.”. The server will then respond with the following message followed by an
arbitrary number.
250 2.0.0 Ok: queued as …
8. Type, quit as the final step and if successful the server will inform you the message is located
in the default mailbox. In this example, the response was…
You have mail in /var/spool/mail/mpoppins.

This completes the SMTP verification for Postfix, be sure to obtain a sing off
from the instructor or teaching assistant before moving on to the next
activity.

4. CONFIGURE CENTOS 7 AS THE MDA (DOVECOT)
Dovecot is the Mail Delivery Agent you will be using for this part of the lab. Dovecot is the default
IMAP and POP3 server for Red hat Enterprise Linux and generally comes pre-installed. IMAP is
preferable to POP3 because only the message header information is downloaded conserving
bandwidth. In other words the message is not downloaded until the user decides they actually want
to read it. This also allows the user to delete messages without having to download them. IMAP
client applications can also cache the message locally removing the need to connect to the IMAP
server. By doing all the work on the server side, IMAP also allows us to keep changes
(read/unread/sent/deleted) synchronized across multiple clients such as web, Thunderbird on the
desktop, and a smartphone. Most importantly, IMAP makes it possible to use SSL/TLS security
measures which you will be configuring in this lab.
4.1. RECREATE THE DOVECOT.CONF FILE
Now that we have confirmed that the SMTP service is working, we’re going to shift our focus to the
IMAP service. IMAP is the protocol used by mail clients to retrieve emails located in their mailbox on
the mail server. Similar to Postfix, it is recommended you back up the original dovecot.conffile. The
modifications made to this file are fairly straight-forward. First we need to tell Dovecot how to

authenticate the user and the simplest way to do this in Linux is using PAM, or Pluggable
Authentication Modules, a topic that will be covered in the next session. In this file we’re going direct
to Dovecot to retrieve the account information from the /etc/passwdfile and Dovecot will need to
use PAM for authentication (1). The next set of statements tell Dovecot that the SMTP service is
being provided by Postfix and define the required permissions (2) (note the unix_listener field, and
the similarity with the smtpd_sasl_path field in the postfix master.conf file). The final set of
statements activate SSL and tell Dovecot where the certificates and keys are located. Remember the
names and locations where you saved these files from section 2. There is also a statement letting
Dovecot know to use IMAP (4). For more information, refer to the Dovecot documentation at
http://wiki2.dovecot.org/.
Figure 6– Example dovecot.conf file
4.2. EDIT /ETC/PAM.D/DOVECOT
PAM or the Pluggable Authentication Module in Linux is used to grant user access to a service once
the user’s identity is verified. Dovecot is a PAM-aware application and the relevant settings file is
located in the “/etc/pam.d”directory. This Linux module centralizes authentication within a Linux
system, so we need to configure a couple lines in the PAM configuration file for Dovecot. The column
to the far left is the “module interface.” In this case, we need to configure authentication (auth) and
the account module interfaces (account), so uncomment those lines. Since both module interfaces
are “required”we can leave the middle column alone. The last column is the “module name”, and

contains two shared objects (so). For the authentication interface set it to “pam_unix.so nullok” and
for the account interface set it to “pam_unix.so”. And that is it for PAM.

Figure 5– PAM Configuration File for Dovecot
4.3. TEST IMAP VIA OPENSSL’S S_CLIENT
Similar to testing SMTP, we can use OpenSSL’s s_client to test SSL and the IMAP service.
1. Type, openssl s_client starttls imap crlf connect mail.fruit.com:143,
this will test that Dovecot is listening for IMAP traffic. As with SMTP, this will begin with
certificate and session information, and then drop you into an interactive shell.
. OK Prelogin capabilities listed, postlogin capabilities have more.
2. Next type, a login mpoppins Password1, using the login and password for the user you
created. And no, the “a” is not a typo. This will verify that Dovecot is accepting login
information. This will return a slew of information from the server ending with something
with “a OK”, if you get the “a OK” you’re in good shape.
* CAPABILITY IMAP4rev1…
a OK Logged in
3. Next check that Dovecot can find the inbox for the user that just logged in by typing, b
select inbox. And no, the “b” is not a typo. This will return the following from the server.
FLAGS (Answered Flagged Deleted Seen Draft)
* OK [PERMANENTFLAGS (Answered Flagged Deleted Seen Draft *)]
Flags permitted.
* 1 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1106186941] UIDs valid
* OK [UIDNEXT 2] Predicted next UID
b OK [READWRITE] Select completed.


4. Finally, to verify the Dovecot configuration settings are correct for this user type, d lsub
“”*. If the server returns the following…

* LSUB () "/" "INBOX"
d OK Lsub completed.

Then the problem is with MUA software on the client side.

5. To gracefully exit the Telnet session type, e logout and the server will return.
* BYE Logging out
e OK Logout completed.
This completes the IMAP verification for Dovecot. Se sure to obtain a sign off from the
instructor or teaching assistant before moving on to the next activity.
5. CONFIGURE CENTOS 7 AS THE MUA (THUNDERBIRD)
Now that the server is up and running, it’s time to introduce a client to the network and verify that we
can send and receive email within the local network. The Mail User Agent is generally a Graphical
User Interface that allows the end user to retrieve emails from the Mail Delivery Agent. If you have
not done so, add a Cent0S 7 VM to your network and install an email client. For this activity and for
demonstration purposes these instruction use Thunderbird.
5.1. CONFIGURE THUNDERBIRD
Once you have Thunderbird installed, we need to configure it. To start Thunderbird, click
Applications →Internet →Thunderbirdfrom the Linux desktop. From the main screen, under
accounts, select Email, under the subheading, “Create a new account:” (Figure 6).

Figure 6– Thunderbird Main Screen
On the following screen, click the button “Skip this and use my existing email”. This will bring you to
the next screen (Figure 7). Enter the user name, email address and password for the user you
created. When finished, click “Continue”.

Figure 7– Mail Account Setup
After clicking continue, Thunderbird will try to automatically configure the settings through the
Mozilla ISP database. This will not work, so just click the “Manual Config” button at the bottom of the
next window. This will bring up the following screen (Figure 8).
Figure 8– Mail Account Setup
Enter the settings for the hostname of the email server in your network, under Port, SSL and
Authentication you can leave the settings to auto configure which is recommended. Click the “Test”
button and once the message, “The following settings were found by probing the given server”

appears, click the “Done” button. You are now ready to test the email server remotely using a Mail
User Agent.
5.2. TEST FUNCTIONALITY
The final activity for this lab requires that you are able to send and receive an email using the local
user account (Figure 9). For the report, you will need to capture the SMTP and IMAP traffic in a
Wireshark trace. If you are running into problems, you can use Telnet to test SMTP and IMAP
remotely, as always this can help with troubleshooting problems. Also, you can check
/var/log/maillogon the remote server for messages that may help identify the root problem.
Once you are able to demonstrate sending and receiving emails using an MUA, obtain a signoff from
the instructor or teaching assistant.
Figure 9– Testing the User Account
This concludes the activities for Lab 8 go forth and report on your findings.

REPORT ACTIVITIES & SIGN-OFFS
Sign-offs
1. Activity 3– Show the teaching assistant or instructor you have confirmed successful configuration
using telnet and SMTP on the local server.
2. Activity 4 – Show the teaching assistant or instructor you have confirmed successful configuration
using telnet and SMTP on the local server.
3. Activity 5– Show the teaching assistant or instructor you have confirmed successful configuration
of Thunderbird and have captured a trace showing SMTP and IMAP traffic.
Report Questions
1. (25 points) Securing Email Communication
1.1. (10 points) Explain what Secure Socket Layer (SSL) is and why it is important for email
communication.
1.2. (10 points) Explain in detail how the key and certificate are used in this lab and how these are
being used by the client email application and the mail server.
1.3. (5 points) What is a “null” client in terms of email communication? What purpose do you
think a “null” client serves?
2. (20 points) Postfix Configuration
2.1. (5 points) Postfix is the service that provides SMTP, it is also the Mail Transport Agent, explain
what the MTA is and its role in email communication.
2.2. (10 points) Include a screenshot of your final Postfix configuration main.cf file. Discuss the
configuration settings in relation to your specific environment. Failure to provide a
screenshot may result in no points awarded for this question.
3. (30 points) Dovecot Configuration
3.1. (5 points) Dovecot is the service that provides the Internet Message Access Protocol (IMAP)
which is also the Mail Delivery Agent. Explain the purpose of the MDA and its role in email
communication.
3.2. (5 points) Explain the differences between POP3 and IMAP from a technical perspective and
your thoughts on which protocol is more relevant for today’s technological requirements.
3.3. (10 points) Explain in general how PAM is used to authenticate users in a Linux environment.
Explain in detail how PAM was used to authenticate your user for email authentication in the
lab.

3.4. (10 points) provide a screenshot of you Dovecot configuration settings. Explain the
configuration settings used and their purpose. Failure to provide a screenshot may result in
no points awarded for this question.
4. (25 points) Testing Functionality
4.1. (5 points) Explain what the MUA is and its role in email communication.
4.2. (10 points) Using your network trace explain the network traffic in the SMTP exchange
between the client and the remote server. Discuss the commands used by both devices.
Failure to reference your trace may result in zero points being awarded for this question.
4.3. (10 points) Using your network trace explain the network traffic in the IMAP exchange
between the client and the remote server. Discuss the commands used by both devices.
Failure to reference your trace may result in zero points being awarded for this question.
5. Report Requirements
At this point in the semester you should be very familiar with the report requirements. From this
point forward you will not be awarded points for observing these requirements. Rather you will
be penalized for not following them. Points deducted will be at the sole discretion of the grader.
FAQS

Lab08Email

More Related Content

Lab08Email