Special Publication 800-45A 

(Draft) 

Guidelines on Electronic Mail 

Security (Draft) 

Recommendations of the National Institute 

of Standards and Technology 

Miles Tracy, Wayne Jansen, Jason Butterfield, 

Karen Kent, and Scott Bisker
ii 

NIST Special Publication 800-45A 

(Draft) 

C O M P U T E R S E C U R I T Y

Computer Security Division 

Information Technology Laboratory 

National Institute of Standards and Technology 

Gaithersburg, MD 20899-8930 

August 2006 

 U .S. Department of Commerce

Carlos M. Gutierrez, Secretary 

 Technology Administration

Robert Cresanti, Under Secretary of Commerce for Technology 

 National Institute of Standards and Technology 

William A. Jeffrey, Director 

Guidelines on Electronic Mail 

Security (Draft) 

Recommendations of the National Institute of 

Standards and Technology 

Miles Tracy, Wayne Jansen, Jason Butterfield, 

Karen Kent, and Scott Bisker 
Reports on Computer Systems Technology 

The Information Technology Laboratory (ITL) at the National Institute of Standards and 

Technology (NIST) promotes the U.S. economy and public welfare by providing 

technical leadership for the Nation’s measurement and standards infrastructure. ITL 

develops tests, test methods, reference data, proof of concept implementations, and 

technical analysis to advance the development and productive use of information 

technology. ITL’s responsibilities include the development of technical, physical, 

administrative, and management standards and guidelines for the cost-effective 

security and privacy of sensitive unclassified information in Federal computer 

systems. This Special Publication 800-series reports on ITL’s research, guidance, and 

outreach efforts in computer security, and its collaborative activities with industry, 

government, and academic organizations.

Certain commercial entities, equipment, or materials may be identified in this 

document in order to describe an experimental procedure or concept adequately. Such 

identification is not intended to imply recommendation or endorsement by the 

National Institute of Standards and Technology, nor is it intended to imply that the 

entities, materials, or equipment are necessarily the best available for the purpose. 

National Institute of Standards and Technology Special Publication 800-45A 

Natl. Inst. Stand. Technol. Spec. Publ. 800-45A, 143 pages (Aug. 2006) 

iii 
iv 

Acknowledgements, Version A 

The authors, Wayne Jansen and Karen Kent of NIST, Miles Tracy of Federal Reserve 

Information Technology, and Jason Butterfield and Scott Bisker of Booz Allen Hamilton, wish 

to express their thanks to colleagues at both organizations who reviewed drafts of this 

document. In particular, their appreciation goes to Linda Antil, Rick Ayers, Bill Burr, and 

Tim Grance from NIST for their research, technical support, and written contributions to this 

version of the document. 

Acknowledgements, Original Version 

The authors, Wayne Jansen of NIST and Scott Bisker and Miles Tracy of Booz Allen 

Hamilton (BAH), wish to express their thanks to colleagues at both organizations who 

reviewed drafts of this document. In particular, their appreciation goes to John Wack, 

Murugiah Souppaya, and Tim Grance from NIST, and Steve Allison, Alexis Feringa, 

Jonathan Holleran, Kevin Kuhlkin, and Mark McLarnon from BAH, for their research, 

technical support, and written contributions to this document. The authors would also like to 

express their thanks to all those who contributed input during the public comment period and 

who assisted with our internal review process. 
Guidelines on Electronic Mail Security (Draft) 

Table of Contents 

EXECUTIVE SUMMARY ...................................................................................................... ES-1 

1. INTRODUCTION .................................................................................................................... 1 

1.1 AUTHORITY....................................................................................................................... 1 

1.2 PURPOSE AND SCOPE......................................................................................................... 1 

1.3 AUDIENCE AND ASSUMPTIONS .......................................................................................... 2 

1.4 DOCUMENT ORGANIZATION.............................................................................................. 2 

2. BACKGROUND AND STANDARDS.................................................................................... 4 

2.1 BACKGROUND ................................................................................................................... 4 

2.2 MULTIPURPOSE INTERNET MAIL EXTENSIONS .................................................................. 5 

2.3 MAIL TRANSPORT STANDARDS ......................................................................................... 6 

2.4 CLIENT ACCESS STANDARDS ............................................................................................ 9 

3. EMAIL-RELATED ENCRYPTION STANDARDS............................................................. 14 

3.1 OPENPGP........................................................................................................................ 15 

3.2 S/MIME.......................................................................................................................... 17 

3.3 ENCRYPTION ALGORITHM SELECTION ............................................................................ 19 

3.4 KEY MANAGEMENT ........................................................................................................ 20 

3.5 OPENPGP VERSUS S/MIME SELECTION ......................................................................... 20 

4. PLANNING AND MANAGEMENT OF MAIL SERVERS................................................. 22 

4.1 PLANNING THE INSTALLATION AND DEPLOYMENT OF A MAIL SERVER........................... 22 

4.2 SECURITY MANAGEMENT STAFF..................................................................................... 24 

4.3 MANAGEMENT PRACTICES.............................................................................................. 26 

4.4 SYSTEM SECURITY PLAN................................................................................................. 27 

4.5 HUMAN RESOURCES REQUIREMENTS.............................................................................. 28 

4.6 GENERAL INFORMATION SYSTEM SECURITY PRINCIPLES................................................ 29 

5. SECURING THE OPERATING SYSTEM ........................................................................... 31 

5.1 SECURELY UPDATING AND CONFIGURING AN OPERATING SYSTEM ................................ 32 

5.2 SECURITY TESTING THE OPERATING SYSTEM ................................................................. 37 

5.3 SECURING THE MAIL SERVER OPERATING SYSTEM CHECKLIST...................................... 38 

6. MAIL SERVER AND CONTENT SECURITY .................................................................... 40 

6.1 HARDENING THE MAIL SERVER APPLICATION ................................................................ 40 

6.2 PROTECTING EMAIL FROM MALWARE............................................................................. 42 

6.3 BLOCKING SPAM-SENDING SERVERS .............................................................................. 52 

6.4 AUTHENTICATED MAIL RELAY ....................................................................................... 53 

6.5 SECURE ACCESS.............................................................................................................. 54 

6.6 ENABLING WEB ACCESS ................................................................................................. 55 

6.7 MAIL SERVER AND CONTENT SECURITY CHECKLIST ...................................................... 56 

7. IMPLEMENTING A SECURE NETWORK FOR A MAIL SERVER................................. 58 

7.1 NETWORK COMPOSITION AND STRUCTURE ..................................................................... 58 

7.2 NETWORK ELEMENT CONFIGURATION ............................................................................ 62 

7.3 NETWORK INFRASTRUCTURE CHECKLIST........................................................................ 69 

v 
Guidelines on Electronic Mail Security (Draft) 

8. MAIL CLIENT SECURITY................................................................................................... 71 

8.1 SECURING INSTALLING, CONFIGURING, AND USING CLIENT APPLICATIONS ................... 71 

8.2 SECURE MESSAGE COMPOSITION.................................................................................... 75 

8.3 PLUG-INS......................................................................................................................... 76 

8.4 ACCESSING WEB-BASED EMAIL SYSTEMS ...................................................................... 76 

8.5 MAIL CLIENT (MUA) SECURITY CHECKLIST .................................................................. 77 

9. SECURELY ADMINISTERING A MAIL SERVER............................................................ 79 

9.1 LOGGING......................................................................................................................... 79 

9.2 MAIL SERVER BACKUP PROCEDURES.............................................................................. 82 

9.3 RECOVERING FROM A SECURITY COMPROMISE ............................................................... 85 

9.4 SECURITY TESTING MAIL SERVERS................................................................................. 87 

9.5 REMOTELY ADMINISTERING A MAIL SERVER ................................................................. 89 

9.6 SECURELY ADMINISTERING A MAIL SERVER CHECKLIST................................................ 90 

APPENDIX A. GLOSSARY...................................................................................................... A-1 

APPENDIX B. MAIL-RELATED RFCS................................................................................... B-1 

APPENDIX C. REFERENCES.................................................................................................. C-1 

APPENDIX D. EMAIL SECURITY TOOLS AND APPLICATIONS..................................... D-1 

APPENDIX E. ONLINE ELECTRONIC MAIL SECURITY RESOURCES............................E-1 

APPENDIX F. EMAIL SERVER AND CLIENT SECURITY CHECKLISTS.........................F-1 

SECURING THE MAIL SERVER OPERATING SYSTEM...................................................................F-1 

MAIL SERVER AND CONTENT SECURITY CHECKLIST ................................................................F-2 

NETWORK INFRASTRUCTURE CHECKLIST..................................................................................F-4 

MAIL CLIENT (MUA) SECURITY CHECKLIST ............................................................................F-5 

SECURELY ADMINISTERING A MAIL SERVER CHECKLIST..........................................................F-7 

APPENDIX G. ACRONYM LIST............................................................................................. G-1 

INDEX................................................................................................................................. INDX-1 

vi 
Guidelines on Electronic Mail Security (Draft) 

Figures and Tables 

Figure 2.1: Example of Message Flow .........................................................................................................5

Figure 2.2: SMTP Commands ......................................................................................................................7

Figure 2.3: Sample SMTP Conversation ......................................................................................................7

Figure 2.4: Sample ESMTP Conversation....................................................................................................8

Table 2.1: SMTP Extensions ........................................................................................................................9

Figure 2.5: POP 3 Commands ....................................................................................................................10

Figure 2.6: IMAP 4 Revision 1 Commands................................................................................................11

Table 2.2: IMAP Extension RFC Documents.............................................................................................12

Table 3.1: OpenPGP Software Sources ......................................................................................................15

Table 3.2: Recommended OpenPGP Cipher Suites....................................................................................16

Table 3.3: S/MIME CAs.............................................................................................................................20

Figure 6.1: Malware Scanning Implemented on Firewall...........................................................................45

Figure 6.2: Malware Scanning Implemented on Mail Server.....................................................................46

Figure 6.3: Malware Scanning Implemented on User Workstations..........................................................48

Figure 6.4: Sendmail TLS Configuration Example from sendmail.mc ......................................................54

Figure 7.1: Simple Single-Firewall DMZ...................................................................................................59

Figure 7.2: Two-Firewall DMZ ..................................................................................................................60

Figure 7.3: Three Interface Firewall DMZ .................................................................................................60

Figure 7.4: Mail Gateway ...........................................................................................................................62

vii 
Guidelines on Electronic Mail Security (Draft) 

Executive Summary 

Electronic mail (email) is perhaps the most popularly used system for exchanging business 

information over the Internet (or any other computer network). At the most basic level, the email 

process can be divided into two principal components: (1) mail servers, which are hosts that 

deliver, forward, and store mail; (2) clients which interface with users and allow users to read, 

compose, send, and store email messages. This document addresses the security issues of both 

mail servers and mail clients. 

Mail servers and user workstations running mail clients are frequently targeted by attackers. 

Because the computing and networking technologies that underlie email are ubiquitous, it is well 

understood and attackers are able to develop attack methods to exploit the technology. Mail 

servers are also targeted because they (and public Web servers) must communicate to some 

degree with untrusted third parties. Additionally, email clients have been targeted as an effective 

means of inserting malware into machines and of propagating this code to other machines. As a 

result, mail servers, mail clients, and the network infrastructure that supports them must be 

protected. Examples of email security issues include the following: 

 Since exchanging email with the outside world is a requirement for most organizations, email 

is allowed through their network perimeter defenses. Because of this, attackers are 

increasingly using email as a vector for their attacks. At a basic level, viruses and other types 

of malware may be distributed throughout an organization via email. Increasingly, however, 

attackers are getting more sophisticated and are using email to deliver targeted zero-day attacks 

to users in an attempt to compromise their workstations. If successful, the attackers will then 

have an attack platform within the organization’s internal network. 

 Given email’s nature of human to human communication, it can be used as a social 

engineering vehicle. Email can allow an attacker to exploit an organization’s users to gather 

information or get the users to perform actions that further an attack. 

 Flaws in the mail server application may be used as the means of compromising the underlying 

server and hence the attached network. Examples of this unauthorized access include gaining 

access to files or folders that were not meant to be publicly accessible, and being able to 

execute commands and/or install software on the mail server. 

 Denial of service (DoS) attacks may be directed to the mail server or its support network 

infrastructure, denying or hindering valid users from using the mail server. 

 Sensitive information on the mail server may be read by unauthorized individuals or changed 

in an unauthorized manner. 

 Sensitive information transmitted unencrypted between mail server and client may be 

intercepted. All popular email communication standards default to sending usernames, 

passwords, and email messages unencrypted. 

 Information within email messages may be altered at some point between the sender and 

recipient. 

 Malicious entities may gain unauthorized access to resources elsewhere in the organization’s 

network via a successful attack on the mail server. For example, once the mail server is 

ES-1 
Guidelines on Electronic Mail Security (Draft) 

compromised, an attacker could retrieve users’ passwords, which may grant the attacker access 

to other hosts on the organization’s network. 

 Malicious entities may attack external organizations from a successful attack on a mail server 

host. 

 Misconfiguration may allow malicious entities to use the organization’s mail server to send 

email-based advertisements (i.e., spam). 

 Users may send inappropriate, proprietary, or other sensitive information via email. This could 

expose the organization to legal action. 

This document is intended to assist organizations in installing, configuring, and maintaining 

secure mail servers and mail clients. More specifically, this document discusses in detail the 

following items: 

 Email standards and their security implications 

 Email-related encryption standards 

 Email-specific aspects of securing the underlying operating system 

 Securing mail server applications 

 Filtering email content 

 Email-specific considerations in the deployment and configuration of network protection 

mechanisms: 

 Firewalls 

 Routers 

 Switches 

 Intrusion detection systems and intrusion prevention systems 

 Securing mail clients 

 Administrating the mail server in a secure manner: 

 Backups 

 Security testing 

 Updating and patching 

 Log reviews 

 Records management/archiving email. 

ES-2 
Guidelines on Electronic Mail Security (Draft) 

The following key guidelines are recommended to Federal departments and agencies for 

maintaining a secure mail server. 

Organizations should carefully plan and address the security aspects of the deployment of a 

mail server. 

As it is much more difficult to address security once deployment and implementation have 

occurred, security should be considered from the initial planning stage. Organizations are more 

likely to make decisions about configuring computers appropriately and consistently when they 

develop and use a detailed, well-designed deployment plan. Developing such a plan will support 

mail server administrators in making the inevitable tradeoff decisions between usability, 

performance, and risk. 

Organizations often fail to take into consideration the human resource requirements for both 

deployment and operational phases of the mail server and supporting infrastructure. 

Organizations should address the following points in a deployment plan: 

 Types of personnel required (e.g., system and mail server administrators, network 

administrators, information systems security officers [ISSO]) 

 Skills and training required by assigned personnel 

 Individual (level of effort required of specific personnel types) and collective manpower 

(overall level of effort) requirements. 

Organizations should implement appropriate security management practices and controls 

when maintaining and operating a secure mail server. 

Appropriate management practices are essential to operating and maintaining a secure mail 

server. Security practices entail the identification of an organization’s information system assets 

and the development, documentation, and implementation of policies, standards, procedures, and 

guidelines that help to ensure the confidentiality, integrity, and availability of information system 

resources. 

To ensure the security of a mail server and the supporting network infrastructure, the following 

practices should be implemented: 

 Organization-wide information system security policy 

 Configuration/change control and management 

 Risk assessment and management 

 Standardized software configurations that satisfy the information system security policy 

 Security awareness and training 

 Contingency planning, continuity of operations, and disaster recovery planning 

 Certification and accreditation. 

ES-3 
Guidelines on Electronic Mail Security (Draft) 

Organizations should ensure that the mail server operating system is deployed, configured, 

and managed to meet the security requirements of the organization. 

The first step in securing a mail server is securing the underlying operating system. Most 

commonly available mail servers operate on a general-purpose operating system. Many security 

issues can be avoided if the operating systems underlying mail servers are configured 

appropriately. Default hardware and software configurations are typically set by manufacturers 

to emphasize features, functions, and ease of use at the expense of security. Because 

manufacturers are not aware of each organization’s security needs, each mail server administrator 

must configure new servers to reflect their organization’s security requirements and reconfigure 

them as those requirements change. Using security configuration guides or checklists can assist 

administrators in securing systems consistently and efficiently. Securing an operating system 

would generally include the following steps: 

 Patch and upgrade the operating system 

 Remove or disable unnecessary services and applications 

 Configure operating system user authentication 

 Configure resource controls 

 Install and configure additional security controls 

 Perform security testing of the operating system. 

Organizations should ensure that the mail server application is deployed, configured, and 

managed to meet the security requirements of the organization. 

In many respects, the secure installation and configuration of the mail server application will 

mirror the operating system process discussed above. The overarching principle, as before, is to 

install the minimal amount of mail server services required and eliminate any known 

vulnerabilities through patches or upgrades. If the installation program installs any unnecessary 

applications, services, or scripts, they should be removed immediately after the installation 

process completes. Securing the mail server application would generally include the following 

steps: 

 Patch and upgrade the mail server application 

 Remove or disable unnecessary services, applications, and sample content 

 Configure mail server user authentication and access controls 

 Configure mail server resource controls. 

Organizations should consider the implementation of encryption technologies to protect 

user authentication and mail data. 

Most standard mail protocols default to unencrypted user authentication and send email data in 

the clear (unencrypted). Sending this data in the clear may allow an attacker to easily 

compromise a user account and/or intercept and alter unencrypted emails. At a minimum, most 

ES-4 
Guidelines on Electronic Mail Security (Draft) 

organizations should encrypt the user authentication session even if they do not encrypt the email 

data itself. Encrypted user authentication is now supported by most standard and proprietary 

mailbox protocols. 

The issues involved with encrypted email data are more complex. Encrypting email places a 

greater load on the user’s computer and the organization’s network infrastructure, may 

complicate malware scanning and mail content filtering, and often requires significant 

administrative overhead. However, for many organizations the benefits of email encryption will 

outweigh the costs. 

Organizations should employ their network infrastructure to protect their mail server(s). 

The network infrastructure (e.g., firewalls, routers, intrusion detection systems) that supports the 

mail server plays a critical role in the security of the mail server. In most configurations, the 

network infrastructure will be the first line of defense between the Internet and a mail server. 

Network design alone, however, cannot protect a mail server. The frequency, sophistication, and 

variety of mail server attacks perpetrated today support the idea that mail server security must be 

implemented through layered and diverse protection mechanisms (layered protection). 

Maintaining the security of a mail server is an ongoing process. 

Maintaining a secure mail server requires constant effort, resources, and vigilance from an 

organization. Securely administering a mail server on a daily basis is an essential aspect of mail 

server security. Maintaining the security of a mail server will usually involve the following steps: 

 Configuring, protecting, and analyzing log files 

 Backing up data frequently 

 Protecting against malware (e.g., viruses, worms, Trojan horses) 

 Establishing and following procedures for recovering from compromise 

 Testing and applying patches in a timely manner 

 Testing security periodically. 

ES-5 
Guidelines on Electronic Mail Security (Draft) 

1. Introduction 

1.1 Authority 

The National Institute of Standards and Technology (NIST) developed this document in 

furtherance of its statutory responsibilities under the Federal Information Security Management 

Act (FISMA) of 2002, Public Law 107-347. 

NIST is responsible for developing standards and guidelines, including minimum requirements, 

for providing adequate information security for all agency operations and assets, but such 

standards and guidelines shall not apply to national security systems. This guideline is consistent 

with the requirements of the Office of Management and Budget (OMB) Circular A-130, Section 

8b(3), “Securing Agency Information Systems,” as analyzed in A-130, Appendix IV: Analysis of 

Key Sections. Supplemental information is provided in A-130, Appendix III. 

This guideline has been prepared for use by Federal agencies. It may be used by 

nongovernmental organizations on a voluntary basis and is not subject to copyright, though 

attribution is desired. 

Nothing in this document should be taken to contradict standards and guidelines made mandatory 

and binding on Federal agencies by the Secretary of Commerce under statutory authority, nor 

should these guidelines be interpreted as altering or superseding the existing authorities of the 

Secretary of Commerce, Director of the OMB, or any other Federal official. 

1.2 Purpose and Scope 

The purpose of the Guidelines on Electronic Mail Security is to recommend security practices for 

designing, implementing, and operating email systems on public and private networks. While 

intended as recommended guidance for Federal departments and agencies, it may be used in the 

private sector on a voluntary basis. 

Mail servers are often the most targeted and attacked servers on an organization’s network – 

second only to Web servers. Various types of mail content and attachments have also proven to 

be effective in introducing viruses and other malware into networks through email clients. Email 

is increasingly being used as a vector to deliver attacks that exploit vulnerabilities in users’ 

workstations or use social engineering methods to trick users. These attacks often lead to the 

compromise of the user workstation or the release of sensitive information even when the email 

client is securely configured. This document may be used by organizations interested in 

enhancing security on existing and future email systems to reduce the number and frequency of 

email-related security incidents. This document presents generic principles that apply to all 

systems. 

This guideline does NOT cover the following aspects relating to securing a mail server: 

 Securing other types of network servers 

 Firewalls and routers used to protect mail servers beyond a basic discussion in Section 7.2.1

 Special considerations for high traffic mail servers with multiple hosts 

1 
Guidelines on Electronic Mail Security (Draft) 

 Securing back-end servers that may support the mail server (e.g., syslog hosts, file servers) 

 Security of the X.400 standard messaging protocol. 

1.3 Audience and Assumptions 

The document, while technical in nature, provides the background information to help readers 

understand the topics that are discussed. The intended audience for this document includes the 

following: 

 Users when setting up email clients and accessing email 

 System engineers and architects when designing and implementing email systems 

 System administrators when administering or upgrading email systems 

 Program managers and information technology (IT) security officers to ensure that adequate 

security measures have been considered for all phases of the system’s life cycle. 

The practices recommended in this document are designed to help mitigate the risks associated 

with email and other known security problems. They build on and assume the implementation of 

practices described in other NIST guidelines listed in Appendix E. 

1.4 Document Organization 

The remainder of this document is organized into the following eight major sections: 

 Section 2 includes background information and standards relating to email. 

 Section 3 contains information on two popular email encryption standards. 

 Section 4 discusses the planning and management of a mail server. 

 Section 5 presents an overview of securing the underlying operating system of a mail server. 

 Section 6 discusses securing a mail server application, protecting messages traversing the 

server, and securing access to mailboxes. 

 Section 7 addresses protecting a mail server through the supporting network infrastructure. 

 Section 8 provides information regarding email client security. 

 Section 9 discusses the basics of securely administering a mail server on a daily basis. 

The document also contains several appendices with supporting material. 

 Appendix A defines terms used in this document. 

 Appendix B lists relevant Request for Comment (RFC) documents. 

 Appendix C lists references used in this document. 

2 
Guidelines on Electronic Mail Security (Draft) 

 Appendix D identifies email security tools and applications. 

 Appendix E lists online email security resources. 

 Appendix F presents a set of email server and client security checklists. 

 Appendix G lists the acronyms used throughout the document. 

 Appendix H contains the index for the document. 

3 
Guidelines on Electronic Mail Security (Draft) 

2. Background and Standards 

As of March 2006, the estimated number of Internet users worldwide exceeded one billion.1 

Most of these users have electronic mail (email) accounts on one or more email systems, which is 

a huge leap from its inception in 1971, when Ray Tomlinson, a Department of Defense (DoD) 

researcher, sent the first ARPANET email message to himself. The ARPANET, precursor to the 

Internet, was a United States (U.S.) Advanced Research Project Agency (ARPA) project intended 

to develop a set of communications protocols to transparently connect computing resources in 

various geographical locations. Messaging applications were available on ARPANET systems; 

however, they could only be used for sending messages to users with local system accounts. 

Tomlinson modified the existing messaging system so that users could send messages to users on 

other ARPANET connected systems. After Tomlinson’s modification was available to other 

researchers, email quickly became the most heavily used application on the ARPANET. 

As the ARPANET evolved into the Internet, email remained one of the most heavily used 

applications for personal and business users. Since the ARPANET was initially a small and 

trusted community, there was little need for security. As the Internet grew in popularity, the need 

for security increased greatly. Unfortunately, the needed security was lacking because early 

email standards and implementations placed little emphasis on security. Maintaining 

compatibility with these standards presents a great challenge in securing email today. 

2.1 Background 

An understanding of how email messages are composed, delivered, and stored is helpful in 

understanding email security. For most email users, once a message is composed and sent, it 

leaves their system and magically appears in the intended recipient’s inbox. This may seem 

simple but the handling and delivery of an email message can be as complex as that involving 

physical mail, with processing and sorting occurring at several intermediary locations before 

arriving at the final destination. 

The process starts with message composition. The most basic email clients typically ask the user 

to provide the following: subject line, message body, and intended recipients. When these fields 

are completed and the user sends the message, the message is transformed into a specific standard 

format specified by Request for Comments (RFC) 2822, Internet Message Format. At the most 

basic level, the two primary message sections are the header and the body. The header section 

contains the vital information about the message including origination date, sender, recipient(s), 

delivery path, subject, and format information. The body of the message contains the actual 

content of the message.2

Once the message is translated into an RFC 2822 formatted message, it can be transmitted. Using 

a network connection, the mail client, referred to as a mail user agent (MUA), connects to a mail 

transfer agent (MTA) operating on the mail server. After initiating communication, the mail 

client provides the sender’s identity to the server. Next, using the mail server commands, the 

client tells the server who the intended recipients are. Although the message contains a list of 

 

1

 World Internet Usage And Population Statistics, http://www.internetworldstats.com/stats.htm. 

2

 Refer to RFC 2822 for additional information on message headers. Appendix B contains a comprehensive list of 

email-related RFCs that includes the URLs for many mail-related RFCs. 

4 
Guidelines on Electronic Mail Security (Draft) 

intended recipients, the mail server does not examine the message for this information. Only 

after the complete recipient list is sent to the server does the client supply the message. From this 

point, message delivery is under control of the mail server. 

Once the mail server is processing the message, several events occur: recipient server 

identification, connection establishment, and message transmission. Using Domain Name 

System (DNS) services, the sender’s mail server determines the mail server(s) for the recipient(s). 

Then, the server opens up a connection(s) to the recipient mail server(s) and sends the message 

employing a process similar to that used by the originating client. At this point, one of two events 

could occur. If the sender’s and recipient’s mailboxes are located on the same mail server, the 

message is delivered using a local delivery agent (LDA). If the sender’s and recipient’s 

mailboxes are located on different mail servers, the send process is repeated from one MTA to 

another until the message reaches the recipient’s mailbox. 

When the LDA has control of the message, a number of possible events may occur. Depending 

on the configuration, the LDA could deliver the message or process the message based on a 

predefined message filter before delivery (filtering can be based on a number of message 

properties and will be discussed in detail in Section 6.2.2). Once the message is delivered, it is 

placed in the recipient’s mailbox where it is stored until the recipient performs some action on it 

(e.g., read, delete) using the MUA. Figure 2.1 illustrates the flow of the message through the 

various mail components discussed previously. This is the general process of sending an email. 

Figure 2.1: Example of Message Flow 

2.2 Multipurpose Internet Mail Extensions 

RFC 2822 provides a standard for transmitting messages containing textual content; however, it 

does not address messages that contain attachments, such as a mail message with a word 

processing document or photo included. Making use of the headers in an RFC 2822 message, the 

Multipurpose Internet Mail Extensions (MIME) provide almost endless possibilities to describe 

the structure of rich message content. MIME uses the convention of content-type/subtype pairs to 

specify the native representation or encoding of associated data. Examples of content types 

include the following: 

 Audio – for transmitting audio or voice data. 

5 
Guidelines on Electronic Mail Security (Draft) 

 Application – used to transmit application data or binary data. 

 Image – for transmitting still image (picture) data. 

 Message – for encapsulating another mail message. 

 Multipart – used to combine several message body parts, possibly of differing types of data, 

into a single message. 

 Text – used to represent textual information in a number of character sets and formatted text 

description languages in a standardized manner. 

 Video – for transmitting video or moving image data, possibly with audio as part of the 

composite video data format. 

The current MIME standards include five parts: RFCs 2045, 2046, 2047, 4289 (which replaced 

2048), and 2049 (see Appendix B). They address message body format, media types, nonAmerican Standard Code for Information Interchange (non-ASCII) message header extensions, 

registration procedures, and conformance criteria, respectively. With this added functionality, 

email features such as message attachments and inline hypertext markup language (HTML) are 

possible. Although MIME extensions allow for binary message content, such content is 

incorporated into an RFC 2822 message using Base64 encoding, which provides a textual 

representation of binary data.3

 

2.3 Mail Transport Standards 

To ensure reliability and interoperability among various email applications, mail transport 

standards were established. In the simplest scenario, an email message is sent from one local user 

to another local user. For this case, an LDA is responsible for placing the message in the 

appropriate mailbox. When a message is sent to non-local recipients, an MTA is needed to send 

the message from the local mail server to the remote mail server. Depending on the type of 

systems involved, different MTAs may be used, which in turn may support different 

implementations of a particular message transfer protocol or more than one distinct transfer 

protocol. 

The most common MTA transfer protocol is the Simple Mail Transfer Protocol (SMTP). SMTP 

is the de-facto Internet standard for sending email messages. Thus, any Internet messaging 

system must support SMTP to facilitate communication with other email messaging applications. 

Other messaging systems exist that use different MTA transfer protocols between similar or 

clustered messaging systems. For the most part, these MTAs are proprietary and work only with 

specific systems. Sections 2.3.1 and 2.3.2 provide background information on SMTP and SMTP 

extensions, while Section 2.3.3 discusses proprietary MTAs. 

2.3.1 Simple Mail Transfer Protocol 

Jon Postel of the University of Southern California developed SMTP in August 1982. As RFC 

821, Simple Mail Transfer Protocol, states, “SMTP was developed to ensure a more reliable and 

 

3

 Base64 encoding was originally derived from RFC 1421 for Privacy Enhanced Mail (PEM). 

6 
Guidelines on Electronic Mail Security (Draft) 

efficient way to transport messages.” At the most basic level, SMTP is a minimal language that 

defines a communications protocol for delivering email messages. Figure 2.2 lists the SMTP 

commands and syntax as defined in RFC 2821, Simple Mail Transfer Protocol, which replaced 

RFC 821. 

Figure 2.2: SMTP Commands 

When a user sends an email, the client contacts its SMTP server and conducts a “conversation” 

using the SMTP language. A MUA is typically part of the mail client application (e.g., Outlook, 

Eudora). If a MUA is unavailable, mail messages can be sent using a telnet client connected to 

the SMTP service. Figure 2.3 depicts a sample SMTP conversation using telnet. The telnet and 

SMTP commands entered by the user for this session are shown in bold. During a manual SMTP 

telnet session, the HELP command can be used to determine which of the SMTP commands are 

enabled on the server. 

HELO <domain> (Hello) Connect to the server as specified in <domain> 

MAIL FROM:<reverse-path> Tell the server the sender’s identity as specified in <reverse-path> 

 [Mail-parameters] 

RCPT TO:<forward-path> (Recipient) Tell the server the intended recipient’s identity as specified in 

 [Rcpt-parameters] <forward-path> 

DATA Convey the message body to the server 

RSET (Reset) Reset the server connection 

VRFY <string> (Verify) Ask the receiver to confirm that a user has been identified 

EXPN <string> (Expand) Ask the receiver to confirm that a mailing list has been identified 

HELP [<string>] Obtain help information 

NOOP [<string>] (No operation) Indicate no operation, but signify the sender is still connected 

 (i.e.,“alive”) 

QUIT Close the server connection 

telnet mail.nowhere.com 25 

Connected to mail.nowhere.com. 

Escape character is '^]'. 

220 test.mail.com SMTP Service (Sample Mail Server String) 

HELO test.mail.com 

250 test.mail.com 

MAIL FROM: jdoe@nowhere.com 

250 Sender <jdoe@nowhere.com> Ok 

RCPT TO: jsmith@somewhere.com 

250 Recipient <jsmith@somwhere.com> Ok 

DATA 

354 Ok Send data ending with <CRLF>.<CRLF> 

Hello World! 

. 

250 Message received: GM1BAR00.F4M 

QUIT 

221 mail.nowhere.com SMTP server closing connection. 

Connection closed by foreign host.

Figure 2.3: Sample SMTP Conversation

7 
Guidelines on Electronic Mail Security (Draft) 

2.3.2 Simple Mail Transfer Protocol Extensions 

As the number of email users grew, additional functionality was sought in mail clients and SMTP 

servers. For SMTP servers to support this additional functionality, extensions were added to 

SMTP. In 1993, RFC 1425 introduced the concept of SMTP service extensions. Subsequently, 

RFC 1425 was superseded by RFC 1651 in 1994, RFC 1869 in 1995, and RFC 2821 in 2001. 

These RFCs added three pieces to the SMTP framework: 

 New SMTP commands (RFC 1425) 

 Registry for SMTP service extensions (RFC 1651) 

 Additional parameters for SMTP MAIL FROM and RCPT TO commands (RFC 1869). 

To be compatible with older SMTP servers, there needed to be a method to allow the mail client 

application to determine whether the server supported extensions. This was accomplished 

through the “enhanced hello” (EHLO) command. When connecting to a server, a mail client 

could issue the EHLO command. If the server supported SMTP extensions, it would give a 

successful response and list the extensions that were supported. If the server did not support 

SMTP extensions, it would issue a command failure response prompting the MUA to respond 

with the standard HELO command. Servers that support SMTP extensions, also known as 

Extended SMTP (ESMTP), typically respond with ESMTP in their banner.4

 Figure 2.4 is an 

excerpt from an ESMTP server transaction involving the EHLO command. 

telnet mail.nowhere.com 25 

Connected to mail.nowhere.com. 

Escape character is '^]'. 

220 test.mail.com ESMTP Service (Sample Mail Server String) 

EHLO test.mail.com 

250 test.mail.com says hello 

250-HELP 

250-EXPN 

250 SIZE 20971520 

... 

Figure 2.4: Sample ESMTP Conversation

As depicted in Figure 2.4, the sample server supports only one extension – SIZE. Numerous 

extensions are supported by a variety of SMTP servers. Table 2.1 lists some of the more common 

SMTP extensions and their associated RFCs. In particular, RFC 2554 specifies a new command 

and protocol for identifying and authenticating a user. The default configuration of most mail 

servers typically does not have authenticated relay enabled. 

 

4

 Many application services (e.g., email, Web, File Transfer Protocol) that operate on a server respond to a client 

request with a banner. This banner is a text message that contains information on the server such application and 

operating system type and version. This information can be useful to attackers and should be changed as discussed 

later in the document. Most mail clients do not display this banner to the end user. 

8 
Guidelines on Electronic Mail Security (Draft) 

Table 2.1: SMTP Extensions 

SMTP Extension Associated RFC

SMTP Service Extension for Authentication 2554

SMTP Service Extension for Command Pipelining 2920

SMTP Service Extension for Delivery Status Notifications (DSNs) 3461

SMTP Service Extension for Message Size Declaration 1870

SMTP Service Extension for Message Tracking 3885

SMTP Service Extension for Remote Message Queue Starting 1985

SMTP Service Extension for Returning Enhanced Error Codes 2034

SMTP Service Extension for Secure SMTP over Transport Layer Security 3207

SMTP Service Extensions for Transmission of Large and Binary MIME Messages 3030

2.3.3 Proprietary Mail Transports 

As mentioned previously, some messaging systems use MTAs that do not support either SMTP or 

ESMTP. These types of MTAs are designed to work within a closed messaging environment. 

Many large-scale government, academic, and private organizations have messaging systems that 

use these types of MTAs. However, these organizations still rely on SMTP or ESMTP-capable 

MTAs for communicating with external messaging systems. Some examples of messaging 

systems that use proprietary protocols are MTAs for Lotus Notes and Microsoft Exchange.5

 

Discussion on the benefits and disadvantages of using MTAs that support only proprietary 

message transfer protocols is outside the scope of this document. 

2.4 Client Access Standards 

Once a message is delivered by the LDA, users need to access the mail server to retrieve the 

message. Mail clients (MUAs) are used to access the mail server and retrieve mail messages. 

Several methods exist for users to access their mailboxes, the simplest being direct access. 

The simplest scenario for a messaging system would be one in which all users have direct access 

to their mailbox (common on hosts employing the Unix operating system). For each account that 

exists on the system, there is a corresponding mailbox in that user’s home directory. When 

messages are received, users can use command line-based mail programs, such as mail or pine, to 

directly access the mailbox. Although this method is straightforward, it requires all users 

accessing the mail server to receive messages to have a user account and a command-line 

interface on the host operating system. 

Allowing users, particularly external users, to have access to a command-line interface is a 

significant security risk. To mitigate this risk, mailbox access protocols were devised. The two 

most widely supported mailbox access protocols are Post Office Protocol (POP) and Internet 

Message Access Protocol (IMAP). They are covered in Sections 2.4.1 and 2.4.2, respectively. 

As with message transfer protocols for MTAs, other proprietary mailbox access protocols exist 

 

5

 These product families have SMTP MTAs as well as their proprietary MTAs. 

9 
Guidelines on Electronic Mail Security (Draft) 

that are regularly used by commercial software manufacturers; proprietary protocols are 

discussed in Section 2.4.3. It is important to understand that POP, IMAP, and indeed most 

proprietary protocols in their default configuration use cleartext passwords for authentication, 

which can be intercepted by other hosts attached to the network. Section 2.4.4 briefly discusses 

the protocols used for Web-based mail clients. 

2.4.1 Post Office Protocol 

POP was first developed in 1984. At its core, POP was nothing more than a way to copy 

messages from the mail server mailbox to the mail client. It worked much like a traditional post 

office mailbox. The mail client opens a connection to the mail server mailbox, downloads the 

mail messages, and then closes the connection. As described in RFC 918, only nine commands 

were originally available for POP (see “Basic Commands” in Figure 2.5). 

Basic Commands from RFC 918 

USER <name> Set username 

PASS <password> Set password 

STAT Check the status of the mailbox, typically retrieves number of messages 

LIST [msg] List messages in the mailbox; Optional argument for message [msg] 

RETR <msg> Retrieve message <msg> 

DELE <msg> Delete message <msg> 

QUIT Quit 

NOOP No operation 

RSET Reset 

Optional Commands from RFC 1939 

TOP <msg> <n> Retrieve the top <n> lines of message <msg> 

UIDL [msg] Retrieve unique id for [msg] 

APOP <name> <digest> A more robust form of authentication than USER/PASS 

Extension Command from RFC 2449 

CAPA Retrieve a list of capabilities supported by the POP3 server 

Figure 2.5: POP 3 Commands 

Since 1984, POP has gone through several changes and is now in its third iteration as defined in 

RFC 1939. The basic command set is very similar to the command set of 1984; however, POP 

version 3 offers a few new optional commands, listed in Figure 2.5. From a security standpoint, 

the addition of the APOP was important, since it avoids transmitting a user’s password in the 

clear. Instead, a challenge/response mechanism is used, by which the client responds with a 

cryptographic hash of the combined challenge sent from the server and the user's password, for 

verification by a POP mail server performing the same operation for the user in question. 

RFC 2449, POP3 Extension Mechanism, defines an extension to POP3 that allows clients to 

discover additional information about POP3 servers, such as which extensions and optional 

commands they support. Figure 2.5 shows the command added to POP3 by the extension. 

The POP mailbox access standard has some significant limitations. Typically, when users 

retrieve their mail, copies of the messages that reside on the server are deleted. This means that 

the user has the sole responsibility of maintaining message archives. Although this may be 

acceptable for personal accounts, it is generally unacceptable for most commercial or 

governmental organizations that have to meet certain legal requirements. In addition, if a user 

10 
Guidelines on Electronic Mail Security (Draft) 

employs several workstations for retrieving mail, the messages are dispersed on multiple systems. 

POP may be configured so that the original messages are not deleted from the server. However, 

the user will have to either download all of the messages previously viewed as well as the new 

messages when accessing a mailbox from another system, or set up a retention period after which 

messages are automatically deleted from the server. 

2.4.2 Internet Message Access Protocol 

To address the above-mentioned issues with POP, IMAP was developed in 1988. The IMAP 

protocol was developed as a functional superset of the POP version 2 protocol. At the most basic 

level, IMAP was designed so user mailboxes could be centrally located and accessed from 

multiple email clients or MUAs. 

Initially, IMAP offered very little functionality beyond that of POP, but since 1988, it has evolved 

into a robust mailbox access protocol. The current edition of the IMAP standard is RFC 3501: 

Internet Message Access Protocol – Version 4, Revision 1 (4rev1). Because IMAP 4rev1 

supports many different features, it has a much wider command set than that of POP. Figure 2.6

provides a list of IMAP 4rev1 commands. Additionally, with the CAPABILITY command, the 

IMAP server can be queried to determine if other IMAP extensions are supported. 

NOOP Perform no operation 

STARTTLS Establish confidentiality and integrity protection 

AUTHENTICATE <type> Choose authentication method 

LOGIN <user> <passwd> Login with username and password 

LOGOUT Logout the current user 

SELECT <mailbox> Select the desired mailbox to access 

EXAMINE <mailbox> Same as SELECT except opens mailbox for read-only 

CREATE <mailbox> Create a mailbox with the name <mailbox> 

DELETE <mailbox> Delete selected mailbox 

RENAME <mailbox> <newmailbox> Rename mailbox 

SUBSCRIBE <mailbox> Subscribe to selected mailbox 

UNSUBSCRIBE <mailbox> Unsubscribe from selected mailbox 

LIST <reference> [pattern] List contents of current reference based on an optional 

pattern 

LSUB <reference> [pattern] List a set of mailboxes matching the pattern 

STATUS <mailbox> <item> Show the status of specific items in the selected mailbox 

APPEND <mailbox> [flags] <msg> Append a message to the selected mailbox 

CHECK Perform a checkpoint on the currently selected mailbox 

CLOSE Close the currently selected mailbox 

EXPUNGE Expunge deleted messages from the mailbox 

SEARCH <criteria> Search the mailbox based on a certain criteria 

FETCH <message> <item> Fetch the specified item from the selected message 

STORE <message> <item> <newvalue> Update the selected item in a message 

COPY <message> <mailbox> Copy a message to the provided mailbox 

UID <command> [args] Perform an operation on a message based on its UID 

CAPABILITY Query the server for its capabilities

Figure 2.6: IMAP 4 Revision 1 Commands 

Table 2.2 lists the associated RFCs for the noted IMAP extensions. IMAP has been extended 

with a challenge/response mechanism comparable to APOP, which is called the ChallengeResponse Authentication Mechanism (CRAM). CRAM requires the client to make note of the 

challenge data sent by the server and respond with a string consisting of the user’s name, a space, 

11 
Guidelines on Electronic Mail Security (Draft) 

and a digest computed by applying a keyed hash algorithm6

 against the timestamp sent with the 

challenge, using a shared secret as the key. 

Table 2.2: IMAP Extension RFC Documents 

IMAP Extension Associated RFC 

IMAP URL Scheme 2192

IMAP/POP AUTHorize Extension for Simple Challenge/Response 2195

IMAP4 ID extension 2971

IMAP4 IDLE command 2177

IMAP4 Login Referrals 2221

IMAP4 Mailbox Referrals 2193

IMAP4 Multi-Accessed Mailbox Practice 2180

IMAP4 Namespace 2342

IMAP4 non-synchronizing literals 2088

IMAP4 QUOTA extension 2087

IMAP4 UIDPLUS extension 4315

2.4.3 Proprietary Mailbox Access Mechanisms 

Proprietary mailbox access protocols are designed to work within closed messaging 

environments. Microsoft Exchange and Lotus Notes are examples of messaging systems that use 

proprietary mailbox access protocols. These proprietary protocols offer additional functionality 

when used with their associated clients. Nearly all proprietary messaging systems support 

standard protocols, including SMTP, POP, and IMAP, in order to interoperate with other types of 

MTAs and MUAs. Organizations must decide for themselves whether it is appropriate to support 

proprietary protocols in their email clients and servers. As mentioned earlier, regardless of 

whether they are standard or proprietary, most access protocols default to weak authentication 

mechanisms (unencrypted authentication information). Therefore, organizations need to 

configure the access protocols to support stronger forms of authentication. 

2.4.4 Web-Based Mail Clients 

Web-based mail clients are increasingly being used as a means of mail service delivery, because 

Web browsers that enable access to the client are available on nearly every Internet-enabled 

device. A user simply runs a Web browser and connects to a Web site that hosts the Web-based 

client. The connection is made using either Hypertext Transfer Protocol (HTTP) or HTTP over 

Transport Layer Security (TLS), also known as HTTPS. HTTPS encrypts the communications, 

which protects both authentication information and mail message content. HTTP alone does not 

 

6

 Most implementations use a popular one-way hash function called MD5. Developed by Ronald Rivest to create a 

message digest for digital signatures, MD5 is faster than SHA-1, but is considered less secure. MD5 is not approved 

for use in securing information for Federal agencies; see Section 3 for more information on this. 

12 
Guidelines on Electronic Mail Security (Draft) 

offer any protection, so organizations should consider using HTTPS for Web-based mail client 

communications. 

Web-based mail clients communicate with their associated mail servers using the same mailbox 

access protocols that traditional mail clients use—SMTP, POP, and IMAP, as well as proprietary 

protocols. The mailbox access protocols are used between the Web servers and mail servers only; 

the protocols are not carried between the Web servers and Web browsers. 

 

13 
Guidelines on Electronic Mail Security (Draft) 

3. Email-Related Encryption Standards 

The two primary mechanisms for securing email content end-to-end are Open Pretty Good 

Privacy (OpenPGP) and Secure/Multipurpose Internet Mail Extensions (S/MIME). Both are 

based in part on the concept of public key cryptography, which involves a user having a pair of 

related keys: a public key that anyone can hold, and a private key that is held exclusively by its 

owner. The recipient’s public key is used for sending encrypted information that can be 

decrypted only with the private key. The sender’s private key is used for sending digitally signed 

information whose authenticity can be verified by anyone holding the corresponding public key. 

Digital signature techniques rely on the creation of a digest or fingerprint of the information (i.e., 

the message being sent) using a cryptographic hash, which can be signed more efficiently than the 

entire message.7

Products based on OpenPGP and S/MIME are capable of both encrypting messages to protect the 

confidentiality of their contents and signing messages to ensure their integrity and confirm the 

identity of a message’s sender. In many cases, messages are signed but not encrypted because the 

confidentiality of the message contents does not need to be protected. If a message needs to be 

encrypted, it is almost always signed as well so that the recipient can ensure the message is 

legitimate. 

Because of the computationally intensive operations involved in public key cryptography, more 

efficient symmetric key cryptography is also used to secure email. Symmetric key cryptography 

requires a single key to be shared between communicating parties, the sender and recipient of an 

email message. The process typically requires the sender to generate a random key and encrypt 

the message with it using a symmetric key encryption algorithm. Then the sender encrypts the 

symmetric key using the recipient’s public key with a corresponding public key encryption 

algorithm, and sends both the encrypted message and encrypted symmetric key to the recipient. 

This hybrid process uses public key encryption only to encrypt the symmetric key. Because only 

the intended message recipient holds the corresponding private key that is needed to recover the 

symmetric key, no other party can decrypt the message and read it. 

Although S/MIME and OpenPGP are two of the most prevalent email encryption mechanisms 

used today, many mechanisms have been proposed since the invention of email. Two of these 

mechanisms were Privacy Enhanced Mail (PEM), first developed in 1987, and MIME Object 

Security Services (MOSS). Since neither method is broadly used today, they are not discussed in 

this document. 

Although encrypting email provides additional security, it does come at a cost, so organizations 

should carefully weigh the issues associated with encrypting email: 

 Scanning for viruses and other malware and filtering mail content at the firewall and mail 

server is made significantly more complicated by encryption. If the firewall or mail server 

does not have a method for decrypting the email, it cannot read and act upon the contents. 

Scanning might have to be performed on the hosts of the mail clients that perform decryption. 

 

7

 For more detailed information on public key cryptography, please refer to NIST Special Publication (SP) 800-32, 

Introduction to Public Key Technology and the Federal PKI Infrastructure (http://csrc.nist.gov/publications/nistpubs/). 

14 
Guidelines on Electronic Mail Security (Draft) 

 Encryption and decryption requires processor time. Organizations might need to upgrade or 

replace equipment that is not capable of supporting the load of encryption and decryption. 

 Organization-wide use of encryption can require significant ongoing administrative overhead. 

Examples of this would include key distribution, key recovery, and revocation of encryption 

keys. 

3.1 OpenPGP 

OpenPGP is a protocol for encrypting messages and creating certificates using public key 

cryptography. It is based on an earlier protocol, PGP, which was created by Phil Zimmerman and 

implemented as a product first released in June 1991. The initial PGP protocol was proprietary 

and used some encryption algorithms with intellectual property restrictions. In 1996, version 5.x 

of PGP was defined in IETF RFC 1991, PGP Message Exchange Formats. Subsequently, 

OpenPGP was developed as a new standard protocol based on PGP version 5.x. OpenPGP is 

defined in RFC 2440, OpenPGP Message Format, and RFC 3156, MIME Security with 

OpenPGP.

8

 

Many free and commercial products that use the OpenPGP standard are currently available. The 

software can be downloaded or purchased from a variety of Web sites, including those shown in 

Table 3.1. 

Table 3.1: OpenPGP Software Sources 

Organization URL

Free Software Foundation http://www.gnupg.org/ 

Hushmail http://www.hushmail.com/ 

International PGP Site http://www.pgpi.org/

OpenPGP Site http://www.openpgp.org/ 

PGP Site (Commercial Version) http://www.pgp.com/ 

Some OpenPGP-based products fully support the cryptographic algorithms recommended to the 

Federal government by NIST in FIPS PUB 140-2 and other publications, including the following 

algorithms:9

 Triple Data Encryption Standard (3DES)10 for data encryption 

 Advanced Encryption Standard (AES)11 for data encryption 

 

8

 The IETF working group for OpenPGP has a Web site at http://www.ietf.org/html.charters/openpgp-charter.html. 

9

 FIPS PUB 140-2, Security Requirements for Cryptographic Modules; FIPS PUB 180-2, Secure Hash Standard (SHS), 

and FIPS PUB 186-2, Digital Signature Standard (DSS) are available at 

http://csrc.nist.gov/publications/fips/index.html. 

10 For more information about DES and 3DES, see http://csrc.ncsl.nist.gov/cryptval/. 

15 
Guidelines on Electronic Mail Security (Draft) 

 Digital Signature Algorithm (DSA)12 for digital signatures 

 RSA algorithm for digital signatures 

 Secure Hash Algorithm (SHA-1, SHA-256)13 for hashing. 

Some implementations of OpenPGP may support other encryption schemes not addressed here. 

Federal organizations are required to use algorithms that have been approved by the Federal 

government.14 Other organizations may wish to choose encryption schemes approved by the 

Federal government because these are well-tested and secure. Many non-approved algorithms 

have been broken. Thus, non-approved algorithms (whether successfully broken or not) may 

represent a significant vulnerability to organizations that employ them. If an organization 

chooses OpenPGP-based products, they should apply the guidelines shown in Table 3.2: 

Table 3.2: Recommended OpenPGP Cipher Suites 

Recommended Use Cipher Suites

Highest Security: Encryption: Advanced Encryption Standard (AES) 

128, 192, or 256-bit encryption 

Authentication & Digest: Digital Signature Standard 

(DSS) or RSA with a key size of 2048 bits or higher 

and SHA with a digest size of 256 bits (SHA-256)

Security and Performance: Encryption: AES 128-bit encryption 

Authentication & Digest: DSS or RSA with a key 

size of 1024 bits or higher and SHA-1

Security and Compatibility: Encryption: Triple Data Encryption Standard 

(3DES) 168/112-bit encryption (note: 3DES is 

considerably slower than AES)15

Authentication & Digest: DSS with a key size of 

1024 bits or higher and SHA-1

Authentication and Tamper Detection Authentication & Digest: DSS with a key size of 

1024 bits or higher and SHA-1 or SHA-256 

 

11 For more information about AES, see http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf. 

12 For more information about the DSA and the associated Digital Signature Standard (DSS), see FIPS PUB 186-2, 

Digital Signature Standard (DSS), http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf. 

13 For more information about the SHA and the associated Secure Hash Standard (SHS), see FIPS PUB 180-2, Secure 

Hash Standard (SHS), http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf. NIST has 

recommended that the use of SHA-1 be phased out by 2010 in favor of SHA-224 and other larger, stronger hash 

functions. See http://csrc.nist.gov/hash_standards_comments.pdf for additional information. 

14 Federal agencies are required to use Federal Information Processing Standards (FIPS) approved cryptographic 

algorithms contained in validated cryptographic modules. The Cryptographic Module Validation Program (CMVP) is 

a joint effort between NIST and the Communications Security Establishment (CSE) of the Government of Canada for 

the validation of cryptographic modules against certain FIPS publications. The CMVP Web site is located at 

http://csrc.nist.gov/cryptval/; it includes a complete list of FIPS-approved algorithms. 

15 Please note that “single” (56-bit) DES is now considered insecure for most applications. 

16 
Guidelines on Electronic Mail Security (Draft) 

Although certain aspects of OpenPGP do use public key cryptography, such as digitally signed 

message digests, the actual encryption of the message body is performed with a symmetric key 

algorithm as outlined earlier. The following is a brief description of signing and encrypting a 

message with OpenPGP (some steps may occur in a different order): 

 OpenPGP compresses the plaintext, which reduces transmission time and strengthens 

cryptographic security by obfuscating plaintext patterns commonly searched for during 

cryptanalysis. 

 OpenPGP creates a random session key (in some implementations of OpenPGP, users are 

required to move their mouse at will within a window to generate random data). 

 A digital signature is generated for the message using the sender’s private key, then added to 

the message. 

 The message and signature are encrypted using the session key and a symmetric algorithm 

(e.g., 3DES, AES). 

 The session key is encrypted using the recipient’s public key and added to the beginning of the 

encrypted message. 

 The encrypted message is sent to the recipient. 

The recipient reverses the steps to recover the session key, decrypt the message, and verify the 

signature. Popular email clients such as Mozilla Thunderbird, Apple Mail, Eudora, and Microsoft 

Outlook require the installation of plug-ins to enable the user to send and receive OpenPGPencrypted messages. The OpenPGP distribution sites listed in Table 3.1 contain instructions on 

how to use OpenPGP with various email client applications. There are also security gateway 

servers available that can use OpenPGP to encrypt, decrypt, sign, and verify signatures on email 

messages on behalf of users. 

3.2 S/MIME 

S/MIME, which was originally proposed in 1995 by RSA Data Security, Inc., is based on their 

proprietary (although widely supported) Public Key Cryptography Standard (PKCS) #7 for data 

format of encrypted messages, and the X.509 version 3 standard for digital certificates.16 

S/MIME version 2 achieved wide adoption throughout the Internet mail industry. Although it is 

not a recognized IETF standard, it is specified by the following informational RFCs: 

 S/MIME Version 2 Message Specification (RFC 2311) 

 S/MIME Version 2 Certificate Handling (RFC 2312) 

 PKCS #1: RSA Encryption Version 1.5 (RFC 2313) 

 

16 For more information about the RSA PKCS standards, consult the PKCS home page 

(http://www.rsasecurity.com/rsalabs/node.asp?id=2124). 

17 
Guidelines on Electronic Mail Security (Draft) 

 PKCS #10: Certification Request Syntax Version 1.5 (RFC 2314) 

 PKCS #7: Cryptographic Message Syntax Version 1.5 (RFC 2315) 

 Description of the RC2 Encryption Algorithm (RFC 2268). 

S/MIME version 3 was developed by the IETF S/MIME Working Group and adopted as an IETF 

standard in July 1999. S/MIME version 3 is specified by the following RFCs: 

 Cryptographic Message Syntax (RFC 3852) 

 S/MIME Version 3 Message Specification (RFC 3851) 

 S/MIME Version 3 Certificate Handling (RFC 3850) 

 Diffie-Hellman Key Agreement Method (RFC 2631) 

 Enhanced Security Services for S/MIME (RFC 2634). 

The IETF S/MIME Working Group now coordinates all current development of the S/MIME 

standard.17

Because it was originally developed in 1995, the S/MIME standard had to conform to the existing 

U.S. export controls for cryptography code. This meant that S/MIME implementations were 

forced to support the insecure 40-bit RC2 algorithm. These controls have since been relaxed. 

However, because of the standing requirement to support 40-bit RC2, S/MIME is sometimes 

criticized as being “cryptographically weak.” This is only accurate if a weak algorithm is chosen. 

No flaws in the actual S/MIME protocol have been announced publicly. However, S/MIME 

clients that encrypt data using 40-bit RC2 can be cracked using a brute force method by Windows 

machines.18 S/MIME is compatible with a number of encryption algorithms that allow it to 

support secure encryption. The actual process by which S/MIME-enabled mail clients send 

messages is similar to that of OpenPGP.19

The most significant feature of S/MIME is its built-in and nearly “automatic” nature. Because of 

heavy industry involvement from manufacturers, S/MIME functionality exists with default 

installations of popular email clients such as Mozilla and Outlook Express. Also, as with 

OpenPGP, there are security gateway servers available that can use S/MIME to encrypt, decrypt, 

sign, and verify signatures on email messages on behalf of users. 

S/MIME version 3.1 supports two encryption algorithms recommended by FIPS PUB 140-2: 

AES, which is recommended but optional for compliant implementations to support, and 3DES, 

which is mandatory for implementations to support. To meet previous export restrictions and for 

backward compatibility, S/MIME also supports RC2 64-bit and DES. Because these are known 

 

17 The homepage for the S/MIME Working Group can be found at http://www.ietf.org/html.charters/smimecharter.html. 

18 http://www.counterpane.com/smime.html

19 The following IBM Redbook provides a detailed example of how S/MIME works: 

http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245341.pdf. 

18 
Guidelines on Electronic Mail Security (Draft) 

to be weak, organizations should not use them for sensitive mail or other transactions. They 

should only be used when no other alternative exists (e.g., export restrictions, compatibility 

issues). RC2 64-bit is stronger than either DES or RC2-40 bit and faster than either DES or 

3DES, though significantly weaker than 3DES. However, algorithm performance is rarely an 

issue with S/MIME, since encryption and decryption usually takes place on a desktop. AES is the 

strongest algorithm currently supported by S/MIME, followed by 3DES. Organizations that 

adopt S/MIME and wish maximum security should ensure that their S/MIME infrastructure is 

configured to use AES or 3DES. 

3.3 Encryption Algorithm Selection 

Choosing an appropriate encryption algorithm depends on several factors that will vary for each 

organization. Although it might appear that the strongest encryption available should always be 

used, that is not necessarily true. The higher the level of the encryption, the greater impact it can 

have on the mail client resources and communications speed, since encryption can increase the 

size of an email considerably. In addition, a number of countries still maintain restrictions on the 

export, import, and use of encryption. Patents and licensing issues may also impact which 

encryption schemes can be used in a particular country. Finally, the choice of email encryption 

standard (OpenPGP, S/MIME, etc.) may limit the choice of encryption algorithms. Fortunately, 

for Federal organizations, the choice is simple and clear—either 3DES or AES. 

Factors that can influence the choice of an encryption algorithm include the following items: 

 Protection. 

 Value of the data to either the organization and/or other entities. The more valuable the 

data, the stronger the required encryption. 

 Time value of data. If data are valuable for only a short time period (e.g., days as opposed 

to years), then a weaker encryption algorithm can be used. An example would be 

passwords that are changed on a daily basis because the encryption needs to protect the 

password for only a 24-hour period. 

 Threat to data. The higher the threat level, the stronger the required encryption. 

 Other protective measures may reduce the need for stronger encryption. An example 

would be using protected methods of communications such as dedicated circuits instead of 

the public Internet. 

 Performance. Requirements for high performance may necessitate weaker encryption, but 

this is not normally a consideration with email. 

 System resources. Lesser resources such as processor speed and memory size (e.g., for 

handheld devices) may necessitate weaker encryption, but are not typically a factor in email. 

 Legal restrictions. The aforementioned import, export, or usage restrictions maintained by 

some countries are a good example of a factor for consideration. 

 Encryption schemes. The cryptographic suites supported by mail client applications and 

operating systems may impose constraints on the algorithms selected. 

19 
Guidelines on Electronic Mail Security (Draft) 

3.4 Key Management 

The biggest difference between OpenPGP and S/MIME is the key management model. The 

default and traditional model that OpenPGP uses for key management is referred to as the “web 

of trust”, which has no central key issuing or approving authority. The web of trust relies on 

users for management and control. While this is suitable for individual users and very small 

organizations, the overhead of such a system is unworkable in medium to large organizations. 

Conversely, S/MIME works on a classic, more hierarchical design. Typically, there is a master 

registration and approving authority, referred to as a Certificate Authority (CA), with subordinate 

local registration authorities. Table 3.3 shows a sample of third-party S/MIME CAs. 

Table 3.3: S/MIME CAs 

CA Name URL 

Entrust http://www.entrust.com/ 

Thawte http://www.thawte.com/ 

Verisign http://www.verisign.com/ 

By default, S/MIME-enabled mail clients depend on the trust of their immediate master CA when 

processing S/MIME transactions. This authority can be either a third-party CA, such as those 

listed in Table 3.3, or a CA that is controlled by the organization issuing the certificates. 

Having an organization exchange OpenPGP or S/MIME-protected emails with other 

organizations is usually extremely complicated, especially when attempting to maintain 

transparency for the users. The biggest challenges are key exchange and establishing trust 

relationships between the organizations. Organizations can connect their PKIs or use a mutually 

trusted third-party PKI, but in either case there are often technical and legal or regulatory 

challenges. Also, support for OpenPGP and S/MIME varies considerably depending on the email 

client in use. There are also third-party services that allow organizations to exchange encrypted 

email without having to establish trust relationships or worry about mail application 

compatibility, but the use of such services necessitates placing sensitive messages on third-party 

servers, which itself can be a security concern. 

Work is currently underway on a possible method of reducing these key management concerns. 

Identity-based encryption (IBE) is a form of public key encryption that allows any string to be 

used as a public key. By using email addresses as public keys, IBE could simplify key 

management, making it much easier for senders to protect the emails that they send. OpenPGP 

and S/MIME standards do not yet support IBE, but Internet-Drafts have been started that propose 

how IBE could be performed using S/MIME. 

3.5 OpenPGP versus S/MIME Selection 

Choosing between OpenPGP and S/MIME depends on a number of factors. Many email products 

are capable of supporting both protocols. The differences in the protocols themselves, not their 

software implementations, are often the primary factors in making a decision. 

20 
Guidelines on Electronic Mail Security (Draft) 

The advantages of OpenPGP are as follows: 

 Suitable for small groups or single users 

 Does not require, but supports, an external public key infrastructure (PKI) if required 

(S/MIME requires an organization to purchase certificates or set up their own certificate 

authority) 

 Can be used with any mail client application, albeit with more steps. 

The advantages of S/MIME are as follows: 

 Suitable for large groups and organizations 

 Most widely compatible mail encryption standard 

 Support built into most major email client applications 

 More transparent to the end user. 

21 
Guidelines on Electronic Mail Security (Draft) 

4. Planning and Management of Mail Servers 

The most critical aspect of deploying a secure mail server is careful planning prior to installation, 

configuration, and deployment. Careful planning will ensure that the mail server is as secure as 

possible and in compliance with all relative organizational policies. Many mail server security 

and performance problems can be traced back to a lack of planning or management controls. The 

importance of management controls is difficult to overstate. In many organizations, the 

information technology support structure is highly fragmented. This fragmentation leads to 

inconsistencies, and these inconsistencies can lead to security vulnerabilities and other issues. 

4.1 Planning the Installation and Deployment of a Mail Server 

Security should be considered from the initial planning stage at the beginning of the systems 

development life cycle to maximize security and minimize costs. It is much more difficult and 

expensive to address security once deployment and implementation have occurred. Organizations 

are more likely to make decisions about configuring hosts appropriately and consistently when 

they begin by developing and using a detailed, well-designed deployment plan. Developing such 

a plan enables organizations to make informed tradeoff decisions between usability and 

performance, and risk. A deployment plan allows organizations to maintain secure configurations 

and aids in identifying security vulnerabilities, which often manifest themselves as deviations 

from the plan. 

In the planning stages of a mail server, the following items should be considered [CERT00]: 

 Identify the purpose(s) of the mail server. 

 What information categories will be processed on or transmitted through the mail server? 

 What are the security requirements for this information? 

 What other service(s) will be provided by the mail server (in general, dedicating the host 

to being only a mail server is the most secure option)? 

 What are the security requirements for these additional services? 

 Where on the network will the mail server be located (see Section 7.1)? 

 Identify the network services that will be provided on the mail server, such as those supplied 

through the following protocols: 

 SMTP 

 POP 

 IMAP 

 Proprietary email protocols. 

22 
Guidelines on Electronic Mail Security (Draft) 

 Identify any network service software, both client and server, to be installed on the mail server 

and any other support servers. 

 Identify the users or categories of users of the mail server and any support hosts, including 

servers providing Web-based mail access. 

 Determine the privileges that each category of user will have on the mail server and support 

hosts. 

 Decide if and how users will be authenticated and how authentication data will be protected. 

 Determine how appropriate access to information resources will be enforced. 

 Determine which mail server applications meet the organization’s requirements. Consider 

servers that may offer greater security, albeit with less functionality in some instances. Some 

issues to consider include: 

 Cost 

 Compatibility with existing infrastructure 

 Knowledge of existing employees 

 Existing manufacturer relationship 

 Past vulnerability history 

 Functionality 

 Work closely with manufacturer(s) in the planning stage. 

The choice of mail server application may determine the choice of operating system. However, 

to the degree possible, mail server administrators should choose an operating system that provides 

the following [CERT00]: 

 Minimal exposure to vulnerabilities (which can be identified on all operating systems) 

 Ability to restrict administrative or root level activities to authorized users only 

 Ability to deny access to information on the server other than that intended to be available 

 Ability to disable unnecessary network services that may be built into the operating system or 

server software 

 Ability to log appropriate server activities to detect intrusions and attempted intrusions. 

In addition, organizations should consider the availability of trained, experienced staff to 

administer the server and server products. Many organizations have learned the difficult lesson 

that a capable and experienced administrator for one type of operating environment is not 

automatically as effective for another. 

23 
Guidelines on Electronic Mail Security (Draft) 

Given the sensitive nature of the mail server, it is critical that it is located in an area that provides 

a secure physical environment. When planning the location of the mail server, the following 

items should be considered: 

 Does the proposed location offer the appropriate physical security protection mechanisms? 

Examples include: 

 Locks 

 Card reader access 

 Security guards 

 Physical intrusion detection systems (e.g., motion sensors, cameras) 

 Does the proposed location offer the appropriate environmental controls so that the necessary 

humidity and temperature are maintained? 

 Is there a backup power source? 

4.2 Security Management Staff 

Because mail server security is tightly intertwined with the organization’s general information 

system security posture, a number of IT and system security staff may be interested in mail server 

planning, implementation, and administration. This section provides a list of those roles and 

identifies their responsibilities as related to mail server security. These roles may vary with the 

organization, however, and not all organizations will have the identical roles described here. 

4.2.1 Senior IT Management/Chief Information Officer (CIO) 

The Senior IT Management/CIO ensures that the organization’s security posture is adequate. The 

Senior IT Management provides direction and advisory services for the protection of information 

systems for the entire organization. The Senior IT Management/CIO is responsible for the 

following activities that are associated with mail servers: 

 Coordinating the development and maintenance of the organization’s information security 

policies, standards, and procedures 

 Coordinating the development and maintenance of the organization’s change control and 

management procedures 

 Ensuring the establishment of, and compliance with, consistent IT security policies for 

departments throughout the organization 

 Coordinating with upper management, public affairs, and other relevant personnel to produce a 

formal policy and process for email usage guidelines (e.g., personal use, monitoring, 

encryption). 

24 
Guidelines on Electronic Mail Security (Draft) 

4.2.2 Information Systems Security Program Managers 

The Information Systems Security Program Managers oversee the implementation of and 

compliance with the standards, rules, and regulations specified in the organization’s security 

policy. The ISSMs are responsible for the following activities associated with mail servers: 

 Ensuring that security procedures are developed and implemented 

 Ensuring that security policies, standards, and requirements are followed 

 Ensuring that all critical systems are identified and that contingency planning, disaster 

recovery plans, and continuity of operations plans exist for these critical systems 

 Ensuring that critical systems are identified and scheduled for periodic security testing 

according to the security policy requirements of each respective system. 

4.2.3 Information Systems Security Officers 

Information Systems Security Officers (ISSO) are responsible for overseeing all aspects of 

information security within a specific organizational entity. They ensure that the organization’s 

information security practices comply with organizational and departmental policies, standards, 

and procedures. ISSOs are responsible for the following activities associated with mail servers: 

 Developing internal security standards and procedures for the mail server(s) and supporting 

network infrastructure 

 Cooperating in the development and implementation of security tools, mechanisms, and 

mitigation techniques 

 Maintaining standard configuration profiles of the mail servers and supporting network 

infrastructure controlled by the organization, including but not limited to operating systems, 

firewalls, routers, and mail server applications 

 Maintaining operational integrity of systems by conducting security tests and ensuring that 

designated IT professionals are conducting scheduled testing on critical systems. 

4.2.4 Mail Server and Network Administrators 

Mail server administrators are system architects responsible for the overall design, 

implementation, and maintenance of a mail server. Network administrators are responsible for 

the overall design, implementation, and maintenance of a network. On a daily basis, mail server 

and network administrators contend with the security requirements of the specific system(s) for 

which they are responsible. Security issues and solutions can originate from either outside (e.g., 

security patches and fixes from the manufacturer or computer security incident response teams) 

or within the organization (e.g., the security office). The administrators are responsible for the 

following activities associated with mail servers: 

 Installing and configuring systems in compliance with the organizational security policies and 

standard system/network configurations 

25 
Guidelines on Electronic Mail Security (Draft) 

 Maintaining systems in a secure manner, including frequent backups and timely application of 

patches 

 Monitoring system integrity, protection levels, and security-related events 

 Following up on detected security anomalies associated with their information system 

resources 

 Conducting security tests as required. 

4.3 Management Practices 

Appropriate management practices are critical to operating and maintaining a secure mail server. 

Security practices entail the identification of an organization’s information system assets and the 

development, documentation, and implementation of policies, standards, procedures, and 

guidelines that ensure confidentiality, integrity, and availability of information system resources. 

To ensure the security of a mail server and the supporting network infrastructure, organizations 

should implement the following practices: 

 Organizational Information System Security Policy—A security policy should outline who 

in the organization is responsible for particular areas of information security (e.g., 

implementation, enforcement, audit, review). The policy should also specify what the basic 

information system security policies are and their intended internal purpose. The policy must 

be enforced consistently throughout the organization to be effective. Generally, the CIO and 

upper management are responsible for drafting the organization’s security policy. 

 Configuration/Change Control and Management—The process of controlling modification 

to a system’s design, hardware, firmware, and software provides sufficient assurance that the 

system is protected against the introduction of an improper modification before, during, and 

after system implementation. Configuration control leads to consistency with the 

organization’s information system security policy. Configuration control is traditionally 

overseen by a configuration control board that is the final authority on all proposed changes to 

an information system. 

 Risk Assessment and Management—Risk assessment is the process of analyzing and 

interpreting risk. It involves determining an assessment’s scope and methodology, collecting 

and analyzing risk-related data, and interpreting the risk analysis results. Collecting and 

analyzing risk data requires identifying assets, threats, vulnerabilities, safeguards, 

consequences, and the probability of a successful attack. Risk management is the process of 

selecting and implementing controls to reduce risk to a level acceptable to the organization. 

 Standardized Configurations—Organizations should develop standardized secure 

configurations for widely used operating systems and applications. This will provide guidance 

to mail server and network administrators on how to securely configure their systems and 

ensure consistency and compliance with the organizational security policy. Because it only 

takes one insecurely configured host to compromise a network, organizations with a significant 

number of hosts are especially encouraged to apply this recommendation. Section 5 contains 

additional information on standard configurations. 

26 
Guidelines on Electronic Mail Security (Draft) 

 Security Awareness and Training—A security training program is critical to the overall 

security posture of an organization. Making users and administrators aware of their security 

responsibilities and teaching the correct practices helps them change their behavior to conform 

to security best practices. Training also supports individual accountability, which is an 

important method for improving information system security. 

 Contingency, Continuity of Operations, and Disaster Recovery Planning—Contingency 

plans, continuity of operations plans, and disaster recovery plans are established in advance to 

allow an organization or facility to maintain operations in the event of a disruption.20

 Certification and Accreditation—Certification in the context of information systems security 

means that a system has been analyzed as to how well it meets all of the security requirements 

of the organization. Accreditation occurs when the organization’s management accepts that 

the system meets the organization’s security requirements.21 

4.4 System Security Plan 

The objective of system security planning is to improve protection of information system 

resources.22 Plans that adequately protect information assets require managers and information 

owners—directly affected by and interested in the information and/or processing capabilities—to 

be convinced that their information assets are adequately protected from loss, misuse, 

unauthorized access or modification, unavailability, and undetected activities. 

The purpose of the system security plan is to provide an overview of the security and privacy 

requirements of the system and describe the controls in place or planned for meeting those 

requirements. The system security plan also delineates responsibilities and expected behavior of 

all individuals who access the system. The system security plan should be viewed as 

documentation of the structured process of planning adequate, cost-effective security protection 

for a system. It should reflect input from various managers with responsibilities concerning the 

system, including information owners, the system owner, and the senior agency information 

security officer (SAISO). 

For Federal agencies, all information systems must be covered by a system security plan. Other 

organizations should strongly consider the completion of a system security plan for each of their 

systems as well. The information system owner23 is generally the party responsible for ensuring 

that the security plan is developed and maintained and that the system is deployed and operated 

according to the agreed-upon security requirements. 

 

20 For more information, see NIST SP 800-34, Contingency Planning Guide for Information Technology Systems

(http://csrc.nist.gov/publications/). 

21 For more information on certification and accreditation, see NIST SP 800-37, Federal Guidelines for the Security 

Certification and Accreditation of Information Technology Systems (http://csrc.nist.gov/publications/). 

22 For more information on system security plans, see NIST SP 800-18 Revision 1, Guide for Developing Security 

Plans for Federal Information Systems (http://csrc.nist.gov/publications/nistpubs/index.html).

23 The information system owner is responsible for defining the system’s operating parameters, authorized functions, 

and security requirements. The information owner for information stored within, processed by, or transmitted by a 

system may or may not be the same as the information system owner. In addition, a single system may utilize 

information from multiple information owners. 

27 
Guidelines on Electronic Mail Security (Draft) 

In general, an effective system security plan should include the following: 

 System Identification. The first sections of the system security plan provide basic identifying 

information about the system. They contain general information such as the key points of 

contact for the system, the purpose of the system, the sensitivity level of the system, and the 

environment in which the system is deployed. 

 Controls. This section describes the control measures (in place or planned) that are intended 

to meet the protection requirements of the information system. Controls fall into three general 

categories: 

 Management controls, which focus on the management of the computer security system 

and the management of risk for a system.24

 Operational controls, which are primarily implemented and executed by people (as 

opposed to systems). They often require technical or specialized expertise, and often rely 

upon management activities as well as technical controls. 

 Technical controls, which are security mechanisms that the computer system employs. 

The controls can provide automated protection from unauthorized access or misuse, 

facilitate detection of security violations, and support security requirements for 

applications and data. The implementation of technical controls, however, always requires 

significant operational considerations and should be consistent with the management of 

security within the organization. [NIST06a] 

4.5 Human Resources Requirements 

The greatest challenge and expense in developing and securely maintaining a mail server is 

providing the necessary human resources to adequately perform the required functions. Many 

organizations fail to fully realize the amount of expense and skills required to field a secure mail 

server. This failure often results in overworked employees and insecure systems. From the 

initial planning stages, organizations need to determine the necessary human resource 

requirements. Appropriate and sufficient human resources are the single most important aspect of 

mail server security. Organizations should also consider the fact that, in general, technical 

solutions are NOT a substitute for skilled and experienced personnel. 

When considering the human resource implications of developing and deploying a mail server, 

organizations should consider the following: 

 Required Personnel – What types of personnel are going to be required? This would include 

such positions as system and mail server administrators, network administrators, and ISSOs. 

 Required Skills – What are the required skills to adequately plan, develop, and maintain the 

mail server in a secure manner? Examples include operating system administration, network 

administration, active content expertise, and programming. 

 

24 For more detail on management, operational, and technical controls, see NIST SP 800-12, An Introduction to 

Computer Security: The NIST Handbook, and NIST SP 800-100 (DRAFT), Information Security Handbook: A Guide 

for Managers (http://csrc.nist.gov/publications/).

28 
Guidelines on Electronic Mail Security (Draft) 

 Available Personnel – What are the available human resources within the organization? In 

addition, what are their current skill sets and are they sufficient for supporting the mail server? 

Often an organization discovers that its existing human resources are not sufficient and needs 

to consider the following options: 

 Train Current Staff – If there are personnel available but they do not have the requisite 

skills, the organization may choose to train the existing staff in the skills required. While 

this is an excellent option, the organization should ensure that employees meet all 

prerequisites for training. 

 Hire Additional Staff – If there is not enough staff available or they do not have the 

requisite skills, it may be necessary to hire additional personnel. 

Once the organization has staffed the project and the mail server is active, it will be necessary to 

ensure the number and skills of the personnel are still adequate. The threat and vulnerability 

levels of IT systems including mail servers are constantly changing, as is the technology. This 

means that what is adequate today may not be tomorrow. 

4.6 General Information System Security Principles 

When addressing mail server security issues, it is an excellent idea to keep some general 

information security principles in mind [Curt01 and Salt75]: 

 Simplicity—Security mechanisms (and the information systems in general) should be as 

simple as possible. Complexity is at the root of many security issues. 

 Fail-Safe—If a failure occurs, the system should fail in a secure manner by which security 

controls and settings remain in effect and are enforced. It is usually better to lose functionality 

rather than security. 

 Complete Mediation—Rather than providing direct access to information, mediators that 

enforce access policy should be employed. Common examples include file system 

permissions, proxies, firewalls, and mail gateways. 

 Open Design—System security should not depend on the secrecy of the implementation or its 

components. “Security through obscurity” is not reliable. 

 Separation of Privilege—Functions, to the degree possible, should be separate and provide as 

much granularity as possible. The concept can apply to both systems and operators/users. In 

the case of systems, such functions such as read, edit, write, and execute should be separate. In 

the case of system operators and users, roles should be as separate as possible. For example, if 

resources allow, the role of system administrator should be separate from that of the security 

administrator. 

 Least Privilege—This principle dictates that each task, process, or user is granted the 

minimum rights required to perform its job. By applying this principle consistently, should a 

task, process, or user be compromised, the scope of damage is constrained to the limited 

resources available to the compromised entity. 

 Psychological Acceptability—Users should understand the necessity of security. This can be 

provided through training and education. In addition, the security mechanisms in place should 

29 
Guidelines on Electronic Mail Security (Draft) 

present users with sensible options that give them the usability they require on a daily basis. If 

users find the security mechanisms too cumbersome, they may devise ways to work around or 

compromise them. The objective is not to weaken security so it is understandable and 

acceptable, but to train, educate, and design security mechanisms and policies that are usable 

and effective. 

 Least Common Mechanism—When providing a feature to the system, it is best to have a 

process or service gain some function without granting the same function to other parts of the 

system. The ability for the mail server process to access a back-end database, for instance, 

should not also enable other applications on the system to access the back-end database. 

 Defense in Depth—Organizations should understand that a single security mechanism would 

generally prove insufficient. Security mechanisms (defenses) need to be layered so that 

compromise of a single security mechanism is insufficient to compromise a host or network. 

There is no “silver bullet” for information system security. 

 Work Factor—Organizations should understand what it would take to break the system or 

network’s security features. The amount of work necessary for an attacker to break the system 

or network should exceed the value that the attacker would gain from a successful 

compromise. 

 Compromise Recording—Records and logs should be maintained so that if a compromise 

does occur, evidence of the attack is available to the organization. This information can assist 

in securing the network and host after the compromise and assist in identifying the methods 

and exploits used by the attacker. This information can be used to better secure the host or 

network in the future. In addition, this can assist organizations in identifying and prosecuting 

attackers. 

30 
Guidelines on Electronic Mail Security (Draft) 

5. Securing the Operating System 

Protecting a mail server from compromise involves hardening the underlying operating system, 

the mail server application, and the network to prevent malicious entities from directly attacking 

the mail server. The first step in securing a mail server, hardening the underlying operating 

system, is discussed at length in this section. (Securing the mail server application and the 

network are addressed in Sections 6 and 7, respectively). 

All commonly available mail servers operate on a general-purpose operating system. Many 

security issues can be avoided if the operating systems underlying the mail servers are configured 

appropriately. Default hardware and software configurations are typically set by manufacturers 

to emphasize features, functions, and ease of use at the expense of security. Because 

manufacturers are unaware of each organization’s security needs, each mail server administrator 

must configure new servers to reflect their organization’s security requirements and reconfigure 

them as those requirements change. The practices recommended here are designed to help mail 

server administrators configure and deploy mail servers that satisfy their organization's security 

requirements.25 Mail server administrators managing existing mail servers should confirm that 

their systems address the issues discussed. 

The techniques for hardening different operating systems vary greatly; therefore, this section will 

include the generic procedures common in securing most operating systems. Security 

configuration guides and checklists for many operating systems are publicly available; these 

documents typically contain recommendations for settings that improve the default level of 

security, and they may also contain step-by-step instructions for securing systems.26 In addition, 

many organizations maintain their own guidelines specific to their requirements. Some 

automated tools also exist for hardening operating systems and their use is strongly recommended 

(see Appendix D). 

Five basic steps are necessary to maintain basic operating system security: 

 Planning the installation and deployment of the host operating system and other components 

for the mail server 

 Patching and updating the host operating system as required 

 Configuring the host operating system to address security adequately 

 Installing and configuring additional security controls, if needed 

 Testing the host operating system to ensure that the previous four steps adequately address all 

security issues. 

 

25 If Web-based mail access will be provided, administrators should ensure that the associated Web servers are secured 

properly, including securing their operating systems and Web server software. See NIST SP 800-44, Guidelines on 

Securing Public Web Servers, for additional information (http://csrc.nist.gov/publications/nistpubs/). 

26 Checklists and implementation guides for various operating systems and applications are available from NIST at 

http://checklists.nist.gov/. Also, see NIST SP 800-70, Security Configuration Checklists Program for IT Products, 

available at the same Web site, for general information about NIST’s checklists program. 

31 
Guidelines on Electronic Mail Security (Draft) 

The first step is discussed in Section 4.1. The other steps are covered in Sections 5.1 and 5.2. 

5.1 Securely Updating and Configuring an Operating System 

This section provides an overview of the second, third, and fourth steps in the list above. The 

combined result of these steps should be to have reasonable protection for the mail server’s 

operating system. 

5.1.1 Patch and Upgrade Operating System 

Once an operating system is installed, applying needed patches or upgrades to correct for known 

vulnerabilities is essential. Any operating system has known vulnerabilities that should be 

corrected before using it to host a mail server. To adequately detect and correct these 

vulnerabilities, mail server administrators should do the following: 

 Create and implement a patching process27

 Identify vulnerabilities and applicable patches28

 Mitigate vulnerabilities temporarily if needed and if feasible (until patches are available, tested, 

and installed) 

 Install permanent fixes (often called patches, hotfixes, service packs, or updates). 

Administrators should ensure that mail servers, particularly new ones, are adequately protected 

during the patching process. For example, a mail server that is not fully patched or not 

configured securely could be compromised by threats if it is publicly accessible while it is being 

patched. When preparing new mail servers for deployment, administrators should do either of the 

following: 

 Keep the servers disconnected from networks or connect them only to an isolated “build” 

network until all patches have been transferred to the servers through out-of-band means (e.g., 

CDs) and installed, and the other configuration steps listed in Section 5.1 have been 

performed. 

 Place the servers on a virtual local area network (VLAN) or other network segment that 

severely restricts what actions the hosts on it can perform and what communications can reach 

the hosts—only allowing those events that are necessary for patching and configuring the 

hosts. Do not transfer the hosts to regular network segments until all the configuration steps 

listed in Section 5.1 have been performed. 

Administrators should generally not apply patches to mail servers without first testing them on 

another system, because patches can inadvertently cause problems with proper system operation. 

 

27 For more information, see NIST SP 800-40 Version 2.0, Creating a Patch and Vulnerability Management Program, 

which is available at http://csrc.nist.gov/publications/nistpubs/. A single patch management process can be put into 

place for both operating systems and applications (including mail server and mail client software). 

28 To check for vulnerabilities in operating systems, services, and other applications, see the NIST National 

Vulnerability Database (NVD) at http://nvd.nist.gov/. 

32 
Guidelines on Electronic Mail Security (Draft) 

Although administrators can configure mail servers to download patches automatically, the 

servers should not be configured to install them automatically so that they can first be tested. 

5.1.2 Remove or Disable Unnecessary Services and Applications 

Ideally, a mail server should be on a dedicated, single-purpose host. When configuring the 

operating system, disable everything except that which is expressly permitted – that is, disable all 

services and applications, enable only those required by the mail server, and then remove the 

unneeded services and applications. If possible, install the minimal operating system 

configuration that is required for the mail server application. Choose the “minimal installation” 

option, if available, to minimize the effort required in removing unnecessary services. In 

addition, many uninstall scripts or programs are far from perfect in completely removing all 

components of a service; therefore, it is always better to not install unnecessary services. Some 

common types of services and applications that should usually be disabled if not required include 

the following: 

 File and printer sharing services (e.g., Windows Network Basic Input/Output System 

[NetBIOS] file and printer sharing, Network File System [NFS], File Transfer Protocol [FTP]) 

 Default Web servers 

 Wireless networking services 

 Remote control and remote access programs, particularly those that do not strongly encrypt 

their communications (e.g., telnet)29 

 Directory services (e.g., Lightweight Directory Access Protocol [LDAP], Kerberos, Network 

Information System [NIS]) 

 Language compilers and libraries 

 System development tools 

 System and network management tools and utilities, including Simple Network Management 

Protocol (SNMP). 

Removing unnecessary services and applications is preferable to simply disabling them through 

configuration settings, because attacks that attempt to alter settings and activate a disabled service 

cannot succeed when the functional components are completely removed. Disabled services 

could also be enabled inadvertently through human error. 

Eliminating or disabling unnecessary services enhances the security of a mail server in several 

ways [CERT00]: 

 Other services cannot be compromised and used to attack the host or impair the services of the 

mail server. Each service added to a host increases the risk of compromise for that host 

 

29 If a remote control or remote access program is absolutely required and it does not strongly encrypt its 

communications, it should be tunneled over a protocol that provides encryption, such as secure shell (SSH) or IP 

Security (IPsec). 

33 
Guidelines on Electronic Mail Security (Draft) 

because each service is another possible avenue of access for an attacker. Less is more secure 

in this case. 

 The host can be configured to better suit the requirements of the particular service. Different 

services might require different hardware and software configurations, which could lead to 

unnecessary vulnerabilities or negatively affect performance. 

 By reducing services, the number of logs and log entries is reduced; therefore, detecting 

unexpected behavior becomes easier (see Section 9). 

Organizations should determine the services to be enabled on a mail server. Services in addition 

to the mail server service that might be installed include directory protocols to access the 

organization’s user directory and remote administration services. These services may be required 

in certain instances, but they may increase the risks to the server. Whether the risks outweigh the 

benefits is a decision for each organization to make. 

If Web-based mail access is to be provided, the Web server running the mail application should 

be on a separate host from the mail server. Having the Web and mail servers on separate hosts 

limits the impact if one of them is compromised when compared with having the both servers on 

the same host. The benefits of the latter arrangement are efficient and protected communications, 

because the Web and mail servers communicate directly within a host instead of over a network. 

5.1.3 Configuring Operating System User Authentication 

For mail servers, the authorized users who can configure the operating system are limited to a 

small number of designated mail server administrators. The users who can access the mail server, 

however, may range from unrestricted to restricted subsets of the organization’s employees. To 

enforce policy restrictions, if required, the mail server administrator must configure the operating 

system to authenticate a prospective user by requiring proof that the user is authorized for such 

access. 

Enabling authentication by the host computer involves configuring parts of the operating system, 

firmware, and applications, such as the software that implements a network service. In special 

cases, for high-value/high-risk sites, organizations may also use authentication hardware, such as 

tokens or one-time password devices. Use of authentication mechanisms where authentication 

information is reusable (e.g., passwords) and transmitted in the clear over a network is strongly 

discouraged, because the information can be intercepted and used by an attacker to masquerade as 

an authorized user. 

To ensure the appropriate user authentication is in place, take the following steps [CERT00]: 

 Remove or disable unneeded default accounts and groups. The default configuration of 

the operating system often includes guest accounts (with and without passwords), 

administrator or root level accounts, and accounts associated with local and network services. 

The names and passwords for those accounts are well known. Remove or disable unnecessary 

accounts to eliminate their use by attackers, including guest accounts on computers containing 

sensitive information. If there is no requirement to retain a guest account or group, severely 

restrict its access and change the default password in accordance with the organizational 

password policy. 

34 
Guidelines on Electronic Mail Security (Draft) 

For default accounts that need to be retained, change the names (where possible and 

particularly for administrator or root level accounts) and passwords to be consistent with 

the organizational password policy. Default account names and passwords are commonly 

known in the attacker community. 

 Disable non-interactive accounts. Disable accounts (and the associated passwords) that need 

to exist but do not require an interactive login. For Unix systems, disable the login shell or 

provide a login shell with NULL functionality (e.g., /bin/false). 

 Create the user groups. Assign users to the appropriate groups. Then assign rights to the 

groups, as documented in the deployment plan. This approach is preferable to assigning rights 

to individual users because the latter will become unwieldy with large numbers of users. 

 Create the user accounts. The deployment plan identifies who will be authorized to use each 

computer and its services. Create only the necessary accounts. Discourage or prohibit the use 

of shared accounts. 

 Check the organization’s password policy. Set account passwords appropriately. This 

policy should address the following areas: 

 Length – a minimum length for passwords. Specify a minimum length of at least eight 

characters. 

 Complexity – the mix of characters required. Require passwords to contain both 

uppercase and lowercase letters and at least one non-alphanumeric character, and to not be 

a “dictionary” word.30 

 Aging – how long a password may remain unchanged. Require users to change their 

passwords periodically. Administrator or root level passwords should be changed every 

30 to 120 days. User level passwords should also be changed periodically, with the period 

determined by the enforced length and complexity of the password combined with the 

sensitivity of the information protected. When considering the appropriate aging duration, 

the exposure level of user passwords should also be taken into account. 

 Reuse – whether a password may be reused. Some users try to defeat a password aging 

requirement by changing the password to one they have used previously. If possible, 

ensure that users cannot change their password by merely appending characters to the 

beginning or end of their original password (e.g., original password was “mysecret” and is 

changed to “1mysecret” or “mysecret1”). 

 Authority – who is allowed to change or reset passwords and what sort of proof is 

required before initiating any changes. 

 Configure computers to prevent password guessing. It is relatively easy for an 

unauthorized user to try to gain access to a computer by using automated software tools that 

attempt all passwords. If the operating system provides the capability, configure it to increase 

 

30 This would include any personal names, place names, terms, or words in any language that could be found in a 

dictionary or word list. 

35 
Guidelines on Electronic Mail Security (Draft) 

the period between logon attempts with each unsuccessful attempt. If that is not possible, the 

second alternative is to deny login after a limited number of failed attempts (e.g., three). 

Typically, the account is “locked out” for a period of time (such as 30 minutes) or until a user 

with appropriate authority reactivates it. 

The choice to deny login is another situation that requires the mail server administrator to 

make a decision that balances security and convenience. Implementing this 

recommendation can help prevent some kinds of attacks, but it can also allow an attacker to 

make failed login attempts to prevent user access, a denial of service (DoS) condition. 

Failed network login attempts should not prevent an authorized user or administrator from 

logging in at the console. Note that all failed login attempts whether via the network or 

console should be logged. If remote administration is not to be implemented (see Section 

9.5), disable the ability for the administrator or root level accounts to log in from the 

network. 

 Install and configure other security mechanisms to strengthen authentication. If the 

information on the mail server requires it, consider using other authentication mechanisms 

such as biometrics, smart cards, client/server certificates, or one-time password systems. They 

can be more expensive and difficult to implement, but they may be justified in some 

circumstances. When such authentication mechanisms and devices are used, the 

organization’s policy should be changed accordingly. 

As mentioned earlier, attackers using network sniffers can easily capture passwords passed across 

a network in clear text. However, passwords are economical and appropriate if properly 

protected while in transit. Implement authentication and encryption technologies, such as Secure 

Sockets Layer (SSL)/Transport Layer Security (TLS), Secure Shell (SSH), or Virtual Private 

Networks (VPNs) (for remote users), to protect passwords during transmission. Requiring server 

side authentication to be used with encryption technologies reduces the likelihood of successful 

man-in-the-middle attacks. 

5.1.4 Configure Resource Controls Appropriately 

All commonly used modern server operating systems provide the capability to specify access 

privileges individually for files, directories, devices, and other computational resources. By 

carefully setting access controls and denying personnel unauthorized access, the mail server 

administrator can reduce intentional and unintentional security breaches. For example, denying 

read access to files and directories helps to protect confidentiality of information, and denying 

unnecessary write (modify) access can help maintain the integrity of information. Limiting the 

execution privilege of most system-related tools to authorized system administrators can prevent 

users from making configuration changes that could reduce security. It also can restrict the 

attacker’s ability to use those tools to attack the system or other systems on the network. 

5.1.5 Install and Configure Additional Security Controls 

Operating systems often do not include all of the security controls necessary to secure the 

operating system, services, and applications adequately. In such cases, administrators need to 

select, install, and configure additional software to provide the missing controls. Commonly 

needed controls include the following: 

36 
Guidelines on Electronic Mail Security (Draft) 

 Anti-malware software, such as anti-virus software, anti-spyware software, and rootkit 

detectors, to protect the local operating system from malware and to detect and eradicate any 

infections that occur.31 Examples of when anti-malware software would be helpful include a 

mail administrator bringing infected media to the mail server and a network service worm 

contacting the server and infecting it. This software is independent of the anti-malware 

software used to scan the mail passing through the server. For many mail systems, anti-virus 

software is the only form of anti-malware software needed to protect the OS. 

 Host-based intrusion detection software, to detect attacks performed against the mail servers. 

Section 7.2.2 contains additional information on host-based intrusion detection software. 

 Host-based firewalls, to protect the server from unauthorized access.32

 Patch management software, to ensure that vulnerabilities are addressed promptly. Patch 

management software can be used just to apply patches, or also to identify new vulnerabilities 

in the mail server’s operating systems, services, and applications. 

Some mail server administrators also install one or more forms of host-based intrusion detection 

software on their servers. For example, file integrity checking software can identify changes to 

critical system files. 

When planning security controls, mail server administrators should consider the resources that the 

security controls will consume. A server’s performance could degrade if it does not have enough 

memory and processing capacity for the controls. 

5.2 Security Testing the Operating System 

Periodic security testing of the operating system is a vital way to identify vulnerabilities and to 

ensure that the existing security precautions are effective. Methods for testing operating systems 

include vulnerability scanning and penetration testing. Vulnerability scanning usually entails 

using an automated vulnerability scanner to scan a host or groups of hosts on a network for 

application, network, and operating system vulnerabilities. Penetration testing is a testing process 

designed to compromise a network using the tools and methodologies of an attacker. It involves 

iteratively identifying and exploiting the weakest areas of the network to gain access to the 

remainder of the network, eventually compromising the overall security of the network. 

Vulnerability scanning should be conducted periodically, at least weekly to monthly, and 

penetration testing should be conducted at least annually. Because both of these testing 

techniques also are applicable to testing the mail server application, they are discussed in detail in 

Section 9.4.

33

 

31 Additional information on anti-malware software is available from NIST SP 800-83, Guide to Malware Incident 

Prevention and Handling (http://csrc.nist.gov/publications/nistpubs/). 

32 For more information on firewalls, see NIST SP 800-41, Guidelines on Firewalls and Firewall Policy

(http://csrc.nist.gov/publications/nistpubs/). 

33 For information on these and other testing techniques, see NIST SP 800-42, Guideline on Network Security Testing, 

(http://csrc.nist.gov/publications/nistpubs/index.html). 

37 
Guidelines on Electronic Mail Security (Draft) 

5.3 Securing the Mail Server Operating System Checklist 

Completed Action

Plan the configuration and deployment of mail server 

Identify functions of the mail server 

Identify categories of information that will be stored, processed, 

and transmitted through the mail server 

Identify security requirements of information 

Identify a dedicated host to run the mail server 

Identify network services that will be provided or supported by the 

mail server 

Identify users and categories of users of the mail server and 

determine privilege for each category of user 

Identify user authentication methods for the mail server 

Choose appropriate operating system for mail server 

Minimal exposure to vulnerabilities 

Ability to restrict administrative or root level activities to 

authorized users only 

Ability to deny access to information on the server other than that 

intended to be available 

Ability to disable unnecessary network services that may be built 

into the operating system or server software 

Acceptable costs for insurance and liability (some insurers charge 

more for certain operating systems) 

Availability of experienced staff to install, configure, secure, and 

maintain operating system 

Patch and upgrade operating system 

Identify and install all necessary patches and upgrades to the 

operating system 

Identify and install all necessary patches and upgrades to 

applications and services included with the operating system 

Remove or disable unnecessary services and applications 

Disable or remove unnecessary services and applications 

Configure operating system user authentication 

Remove or disable unneeded default accounts and groups 

Disable non-interactive accounts 

Create the user groups for the particular computer 

Create the user accounts for the particular computer 

Check the organization’s password policy, and set account 

passwords appropriately (e.g., length, complexity) 

38 
Guidelines on Electronic Mail Security (Draft) 

Completed Action

Configure computer to deny login after a limited number of failed 

attempts 

Install and configure other security mechanisms to strengthen 

authentication 

Configure resource controls appropriately 

Set access controls for files, directories, devices, and other 

resources 

Limit privileges for most system-related tools to authorized 

system administrators 

Install and configure additional security controls 

Select, install, and configure additional software to provide needed 

controls not included in the operating system 

Test the security of the operating system 

Test operating system after initial install to determine 

vulnerabilities 

Test operating system periodically (e.g. quarterly) to determine 

new vulnerabilities 

39 
Guidelines on Electronic Mail Security (Draft) 

6. Mail Server and Content Security 

Hardening mail server applications is an important step in protecting mail servers from 

compromise. This section provides recommendations for securely installing mail servers and 

configuring operating system and mail server access controls. Another important part of email 

security is protecting the email content that traverses the server, which includes content filtering, 

malware scanning, and spam prevention. Securing access to mailboxes by encrypting 

communications, including Web-based mail access, is also addressed in this section. Email 

content security can also involve email encryption to preserve confidentiality and digital 

signatures to support integrity and non-repudiation; these are discussed in Section 3. 

6.1 Hardening the Mail Server Application 

After ensuring that the mail server’s operating system is secured properly, the next step is to 

install the mail server application and secure it from likely threats. The subsections that follow 

provide an overview of these two actions. 

6.1.1 Securely Installing the Mail Server 

In many respects, the secure installation and configuration of the mail server application mirrors 

the operating system process discussed in Section 5. The overarching principle, as before, is to 

install only the services required for the mail server and to eliminate any known vulnerabilities 

through patches or upgrades. Any unnecessary applications, services, or scripts that are installed 

should be removed immediately once the installation process is complete. During the installation 

of the mail server, the following steps should be performed: 

 Install the mail server software on a dedicated host 

 Apply any patches or upgrades to correct for known vulnerabilities 

 Create a dedicated physical disk or logical partition (separate from operating system and mail 

server application) for mailboxes, or host the mailboxes on a separate server 

 Remove or disable all services installed by the mail server application but not required (e.g., 

Web-based mail, FTP, remote administration) 

 Remove all manufacturer documentation from server 

 Remove any example or test files from server 

 Apply appropriate security template or hardening script to the server 

 Reconfigure SMTP, POP, and IMAP service banners (and others as required) NOT to report 

mail server and operating system type and version (this may not be possible with all mail 

servers) 

 Disable dangerous or unnecessary mail commands (e.g., VRFY and EXPN). 

40 
Guidelines on Electronic Mail Security (Draft) 

6.1.2 Securely Configuring Operating System and Mail Server Access Controls 

Most mail server host operating systems provide the capability to specify access privileges 

individually for files, devices, and other computational resources on that host. Any information 

that the mail server can access using these controls can potentially be distributed to all users 

accessing the mail server. The mail server software is likely to include mechanisms to provide 

additional file, device, and resource access controls specific to its operation. It is important to set 

identical permissions for both the operating system and mail server application; otherwise, too 

much or too little access may be granted to users. Mail server administrators should consider 

how best to configure access controls to protect information stored on their public mail server 

from two perspectives: 

 Limit the access of the mail server application to a subset of computational resources 

 Limit the access of users through additional access controls enforced by the mail server, where 

more detailed levels of access control are required. 

The proper setting of access controls can help prevent the disclosure of sensitive or restricted 

information that is not intended for public dissemination. In addition, access controls can be used 

to limit resource use in the event of a DoS attack against the mail server. 

Typical files to which access should be controlled are as follows: 

 Application software and configuration files 

 Files directly related to security mechanisms: 

 Password hash files and other files used in authentication 

 Files containing authorization information used in controlling access 

 Cryptographic key material used in confidentiality, integrity, and non-repudiation services 

 Server log and system audit files 

 System software and configuration files. 

Ensure that the mail server application executes only under a unique individual user and group 

identity with very restrictive access controls. Thus, new user and group identities to be used 

exclusively by the mail server software need to be established. The new user and new group 

should be independent and unique from all other users and groups. This is a prerequisite for 

implementing the access controls described in the following steps. Although the server may 

initially have to run with root (Unix) or administrator/system (Windows 2000/2003) privileges to 

bind to the necessary TCP ports, do not allow the server to continue to run at this level of access. 

In addition, use the mail server operating system to limit files accessed by the mail service 

processes. These processes should have read-only access to those files necessary to perform the 

service and should have no access to other files, such as server log files. Use mail server host 

operating system access controls to enforce the following: 

41 
Guidelines on Electronic Mail Security (Draft) 

 Temporary files created by the mail server application are restricted to a specified and 

appropriately protected subdirectory (if possible). 

 Access to any temporary files created by the mail server application is limited to the mail 

server processes that created these files (if possible). 

It is also necessary to ensure that the mail server cannot save files outside the specified file 

structure dedicated to the mail server. This may be a configuration choice in the server software, 

or it may be a choice in how the server process is controlled by the operating system. Ensure that 

such directories and files (outside the specified directory tree) cannot be accessed, even if users 

know the locations of those files. 

On Linux and Unix hosts, consider using a “chroot jail” for the mail server application. Using 

chroot changes the mail server’s “view” of the host file system such that the apparent root 

directory is not the real file system root directory but rather one of its subparts. Thus, if the mail 

server is successfully compromised, the attacker only gains access to the limited subpart of the 

file system accessible via chroot. This is a very powerful security measure. 

To mitigate the effects of certain types of DoS attacks, configure the mail server to limit the 

amount of operating system resources it can consume. Some examples include: 

 Installing users’ mail boxes on a different server (preferred), hard drive, or logical partition 

than the operating system and mail server application 

 Configuring the mail server application so that it cannot consume all available space on its 

hard drives or partitions 

 Limiting the size of attachments that are allowed 

 Ensuring log files are stored in a location that is sized appropriately. 

These actions protect to some degree against attacks that attempt to fill the file system on the mail 

server host operating system with extraneous and incorrect information that may cause the system 

to crash. This also protects against attacks that attempt to fill primary random access memory 

with unnecessary processes to slow down or crash the system, thus limiting mail server 

availability. Logging information generated by the mail server host operating system may help in 

recognizing such attacks. As discussed in Section 9.1, administrators should store mail server 

logs on centralized logging servers whenever possible, and also store logs locally if feasible. If 

an attack causes the mail server to be compromised, the attacker could modify or erase locally 

stored logs to conceal information on the attack. Having a copy of the logs on a centralized 

logging server gives administrators more information to use when investigating such a 

compromise. 

6.2 Protecting Email from Malware 

Email has increasingly been used as a means for sending binary files in the form of attachments. 

Initially, this did not pose much of a security risk because attachments were mostly small word 

processing documents or photos. As more organizations began using email for day-to-day 

collaboration, the size and types of email attachments increased. Today, many email messages 

are sent with attachments such as program executables, pictures, music, and sounds. Many forms 

of malware, including viruses, worms, Trojan horses, and spyware—malware intended to violate 

42 
Guidelines on Electronic Mail Security (Draft) 

a user’s privacy—are often transmitted in attachments. Increasingly, attackers are using email to 

deliver zero-day attacks at targeted organizations before these vulnerabilities are known publicly. 

These attacks are often targeted at office productivity software and give the attacker control over 

users’ workstations. This control can be exploited to escalate privileges, gain access to sensitive 

information, monitor users’ actions (e.g., keystrokes), and perform other malicious actions. 

Organizations should determine which types of attachments to allow, which can be a difficult 

decision. Not allowing any attachments would definitely simplify a system and make it much 

more secure; however, it would dramatically reduce its usefulness, and users might employ 

encoding tricks to work around the restriction to “get the job done”. Ultimately, allowing 

attachments is based on organizational needs, and most organizations choose to allow at least 

some email attachments. Organizations might wish to consider different rules for internally 

originated versus externally originated email or trusted versus untrusted organizations (e.g., trust 

.gov/.mil domains) though this latter option is subject to email address spoofing. 

Based on the assumption that email attachments are desired, the mail server administrator should 

determine which types of attachments to allow. The simplest approach is to allow all types of 

attachments. If this is the case, then some sort of malware scanner (e.g., anti-virus software, antispyware software) should be installed in the mail transit path to filter out known malware, and 

perhaps even some behavior blocking utility at the client to prevent any unwanted operations by 

executable attachments from occurring. A better approach is to filter potentially dangerous 

attachment types (e.g., .vbs, .ws, .wsc file extensions) at the mail server or mail gateway, while 

conducting malware scans on allowed file types. Although filtering on such extensions is a good 

first step, its effectiveness is limited because attackers can alter the extensions. Instead of simply 

checking the extension, filtering should check the file header, footer, or other identifying aspects 

of the file if possible to identify the attachment. 

Attachment filtering is not completely effective unless all attachments are blocked, and that is 

rarely feasible. Some of the most useful attachment types, such as those from office productivity 

suites, are also some of the riskiest. Also, sophisticated attackers can obfuscate the true nature of 

their malicious attachments in various ways. For example, attackers sometimes send emails that 

have hyperlinks to a malicious file on a remote Web site; if a user clicks on the hyperlink and it 

uses HTTPS instead of HTTP, the malicious file will be downloaded while protected by HTTPS, 

concealing it from detection by network-based security controls. Organizations could filter active 

hyperlinks in email messages to prevent this, but this would reduce the usability of email 

messages for users. 

Email encryption tends to make filtering more complicated or ineffective. Once a message is 

encrypted, filtering on the mail server and/or perimeter devices is ineffective unless they can 

decrypt the message, scan it, and re-encrypt it. This is problematic because of the huge 

performance requirement. Privacy and other concerns with this sort of solution also exist. 

Generally speaking, if encryption is used extensively, then filtering has to occur at the end point 

(user workstation), which is susceptible to being bypassed. 

Another vector for email-borne malware that is often overlooked is personal email accounts 

accessed via Web browsers. Organizations need to determine if having access to personal email 

accounts from organizational computers is appropriate, and if so, take measures to ensure users 

do not put organization assets at risk when accessing their personal accounts. 

In addition to email attachments, malware can be transmitted via email by other means. For 

example, many emails and email clients support HTML-based messages. These messages often 

43 
Guidelines on Electronic Mail Security (Draft) 

contain active content in the form of a client-side scripting language or control objects that can 

affect the client. The most popular types of active content are ActiveX, Java, JavaScript, and 

Visual Basic Script (VBScript). Organizations should determine whether or not to allow or block 

active content or forms of active content within mail messages.34 HTML-based messages also 

frequently contain other undesirable content, such as spam messages and phishing attempts. 

Phishing refers to use of deceptive computer-based means to trick individuals into disclosing 

sensitive personal information. For example, an attacker could send victims an email message 

that looks as if it were sent from a well-known organization, such as an online business, credit 

card company, or financial institution. The email is intended to deceive users into responding to 

the email and disclosing personal data. 

If a mail server does not have malware scanning software installed (e.g., anti-virus software, antispyware software), or the software is ineffective, the potential security threat posed by malware 

increases for end users. Some popular mail clients have default configurations that are used by 

malware to infect client hosts and transmit malware to other users. Section 8 contains additional 

information on configuring mail clients to improve their security. In addition to mail client 

configuration, it is important that the mail client hosts use anti-virus software and possibly other 

security technologies as well to protect them from mail-borne threats. 

Section 6.2.1 discusses the need for malware scanning for both individual mail clients and the 

mail infrastructure. Sections 6.2.2 and 6.2.3 discuss content filtering technologies that can also 

be helpful at stopping email-borne threats. In addition to deploying and configuring technologies, 

an organization should also conduct training and awareness activities for users, particularly 

telecommuters using computers outside the organization’s control, so that users can better 

recognize malicious mail messages and attachments and handle them appropriately. 

6.2.1 Malware Scanning 

To protect against viruses, worms, and other forms of malware, it is necessary to implement 

scanning at one or more points within the email delivery process. Malware scanning can be 

implemented on the firewall, mail relay, or mail gateway appliance as the mail data enters the 

organization’s network, on the mail server itself, and/or on the end users’ hosts. Each option has 

its own strengths and weaknesses, which are discussed below. Generally, organizations should 

implement at least two levels of malware scanning—one at the end users’ host level and one at 

the mail server or the firewall/mail relay/mail gateway level—and should consider implementing 

malware scanning at all three levels. 

The first option is scanning for malware at the firewall (application proxy), mail relay (see Figure 

6.1), or mail gateway appliance, which can intercept messages before they reach the 

organization’s mail server. The device listens on TCP port 25 for SMTP connections, scans each 

message, then forwards the messages not containing malware to the mail server, which is 

configured to listen on an unprivileged, unused port, rather than the usual port 25. A 

disadvantage to this approach is that constant scanning of the SMTP stream can reduce firewall/ 

mail relay/mail gateway performance. Whether this performance hit is significant depends on 

mail load, including both the typical number of emails per day and the peak rates of emails, and 

 

34 For more information on active content, see NIST SP 800-28, Guidelines on Active Content and Mobile Code, 

(http://csrc.nist.gov/publications/nistpubs/). 

44 
Guidelines on Electronic Mail Security (Draft) 

quality of service requirements. One remedy to improve performance is to offload malware 

scanning to a dedicated server. 

Figure 6.1: Malware Scanning Implemented on Firewall 

The benefits of scanning mail at the firewall, mail relay, or mail gateway appliance are as 

follows: 

 Can scan mail in both directions (inbound and outbound from the organization’s network) 

 Can stop the majority of messages containing malware at the perimeter before they enter the 

network and are passed to the mail server 

 Can implement scanning for inbound mail with minor changes to the existing mail server 

configuration 

 Can reduce the amount of email reaching the mail servers, allowing them to operate more 

efficiently with lower operational costs 

 Can centrally manage scanning to ensure compliance with the organization’s security policy 

and regular application of updated malicious code signatures 

 For some mail firewall appliances, can provide secure authenticated access to Web-based mail 

applications. 

Scanning for malware at the firewall, mail relay, or mail gateway appliance has a number of 

weaknesses: 

 Can require significant modification of the existing mail server configuration when scanning 

mail in the outbound direction 

 Cannot scan encrypted emails 

45 
Guidelines on Electronic Mail Security (Draft) 

 Offers no protection to internal users once malware is on the organization’s internal network, 

unless the network is configured so that SMTP traffic gets routed through a dedicated scanner 

before reaching the mail server 

 May require powerful (expensive) servers or appliances to handle the load of a large 

organization. 

 Can detect only those threats that have been identified; offers little protection against zero-day 

exploits. 

The second option for placement of a mail malware scanner is on the mail server itself (see 

Figure 6.2). Many third-party applications are available to scan the contents of the message 

stores for most popular mail servers. These applications inspect the email sent between internal 

users, which normally do not pass through the organization’s firewall/mail relay/mail gateway. 

Performing scanning on the mail server also provides an additional layer of protection against 

malware, and also helps to stop internal malware outbreaks. Some mail servers offer application 

programming interfaces (API) that support the integration of malware scanning, content filtering, 

attachment blocking, and other security services within the MTA. 

Figure 6.2: Malware Scanning Implemented on Mail Server 

The major disadvantage of implementing malware scanning on the mail server is the negative 

effect on the performance of the mail server caused by the requirement to scan all messages. 

Also disadvantageous is that malware scanning on the mail server often requires significant 

modifications to the existing mail server configuration. However, this option provides a number 

of advantages: 

 Can scan mail in both directions (inbound and outbound) 

 Can be centrally managed to ensure compliance with the organization’s security policy and 

that updates are applied regularly 

 Offers protection to internal users once malware is on the organization’s internal network. 

46 
Guidelines on Electronic Mail Security (Draft) 

Scanning for malware at the mail server has a number of weaknesses: 

 May require significant modification of the existing mail server configuration (less true for 

most newer mail servers) 

 Cannot scan encrypted emails 

 May require more powerful (expensive) servers to handle the load of a large organization. 

 Can detect only those threats that have been identified; offers little protection against zero-day 

exploits. 

When considering mail server-based malware scanners, look for the following qualities: 

 Detects and cleans all types of malware typically carried by email (e.g., viruses, worms, Trojan 

horses, malicious mobile code, spyware) 

 Provides heuristic scanning (provides some protection from new and unknown malware) 

 Provides content filtering (see Section 6.2.2) 

 Incorporates mechanisms to help prevent email from circumventing the system 

 Provides ease of management 

 Provides automated downloading and installation of updates 

 Provides frequent updates (critical) 

 Can identify and apply rules to different types of content 

 Provides a robust and configurable alert mechanism 

 Provides detailed logging capabilities (see Section 9.1). 

Malware scanners can also be located on client hosts (see Figure 6.3). This type of malware 

scanner is installed on user workstations and mobile devices, such as personal digital assistants 

(PDA). Incoming emails are scanned as they are opened by the user, and outbound emails are 

checked as the user attempts to send them. The primary advantage of this type of configuration is 

that scanning is distributed across many hosts and therefore has minimal effect on the 

performance of each individual system. Also, if a client machine becomes infected with 

malware, this layer of protection might stop the malware from spreading to the mail server and 

other mail clients. 

47 
Guidelines on Electronic Mail Security (Draft) 

Figure 6.3: Malware Scanning Implemented on User Workstations 

The greatest challenge of implementing malware scanning on user workstations is the difficulty 

in managing and regularly updating the distributed malware scanners. However, enterprise-level 

solutions for malware scanning provide a means of central administration of malware scanners on 

individual hosts. Another weakness is that to the degree that users have control of the malware 

scanner, end users may disable some or all of its functionality (whether accidentally or 

intentionally). Enterprise solutions offer the capability to lock down some or all of the clients’ 

scanners’ functionality to ensure they are configured correctly. 

The benefits of client-side malware scanning are as follows: 

 Does not require any modification to the mail server 

 Can scan encrypted emails when they are decrypted by the user 

 Distributes malware scanning and thus minimizes the impact of scanning on any one host 

 Offers protection to internal users, even when malware is received from an internal user. 

The disadvantages of client-side malware scanning are as follows: 

 Can be difficult to centrally manage, especially for mobile client systems (e.g., laptops) 

 Can take time before users update malware scanners, resulting in the organization being more 

susceptible to an outbreak 

 Can be intentionally or accidentally disabled or weakened by users. 

 Can detect only those threats that have been identified; offers little protection against zero-day 

exploits. 

To provide multiple layers of malware protection, organizations should consider choosing 

products from different manufacturers. Diversity increases the chances of blocking the latest 

48 
Guidelines on Electronic Mail Security (Draft) 

threats because the response time of individual manufacturers to new threats varies. This means 

that at any time, for the newest threats one product can often detect threats that another product 

cannot yet detect for a period of time (typically hours, perhaps a few days). Since each 

manufacturer uses different detection methods, some products are also better able to detect certain 

types of new threats than other products. 

In addition to using anti-virus software and/or other malware scanning tools, organizations should 

educate users about the dangers posed by email-borne malware and effective ways of avoiding 

threats, including the following actions: 

 Never open attachments from unknown senders. 

 Never open attachments with suspicious or potentially harmful names or file extensions (e.g., 

attachment.txt.vbs, attachment.exe) from known or unknown senders. 

 Be suspicious of emails from known senders in which the subject line or content appears to be 

inappropriate for the existing relationship (e.g., an email with the subject “I love you” from a 

professional colleague) or generic subjects (e.g., “Look at this, it’s interesting”). 

 Scan all attachments with malware scanning software before opening, preferably by 

configuring the scanning software to automatically perform this task. 

 Update the signature database of the malware scanning software on a daily basis or when there 

is a malware outbreak. 

 Warn users about malware outbreaks and how to identify emails that might contain malware. 

Another consideration that should be addressed regarding attachments is the size of the 

attachment itself. Because of the varying storage and processing requirements for larger 

messages, mail servers should restrict the maximum accepted message size. When a binary file, 

such as a picture, is attached to an email message, it is not sent in its native format; rather, it is 

encoded. As mentioned in Section 2.2, binary attachments are represented as blocks of Base64 

encoded text. This type of encoding imposes a 33 percent increase in the message size. For 

example, a message composed of basic headers and a 1 megabyte attachment becomes a message 

that is roughly 1.33 megabytes. 

Implementing a size restriction benefits the mail server in several ways: 

 Decreased mail queue latency 

 Decreased storage requirements 

 Decreased server processor requirements. 

The combination of these benefits decreases the likelihood of the mail server being put into a DoS 

state resulting from a deluge of over-sized messages. [NIST05] 

6.2.2 Content Filtering 

Content filtering works in a similar manner to malware scanning at the firewall or mail server 

except that it is looking for emails containing undesirable content other than malware, such as 

49 
Guidelines on Electronic Mail Security (Draft) 

spam or emails containing inappropriate language. When implementing file-type restrictions and 

malware scanning, only a certain level of security is provided. The contents of an email message 

or its attachments could prove much more damaging to an organization than a virus or rogue 

executable. For this case, some sort of content filtering mechanism should be employed. For 

maximum effectiveness, content filtering should be performed on all incoming and outgoing 

messages and conducted in the same locations as malware scanning—on the firewall/mail 

relay/mail gateway, mail servers, and end users’ hosts. In fact, many products are available for 

popular messaging systems that incorporate content filtering, malware scanning, and file-type 

restriction (see Appendix D for a listing of common products). Incorporation of these features 

into one product can reduce the administration of security controls. 

In general, rules are defined to forward, quarantine, park, clean, block, or delete any data passing 

through the server depending upon the results of the scan. Typical items that would be caught by 

the filter and possible actions taken on them could be as follows: 

 Email that contains suspicious active content (e.g., ActiveX, JavaScript) is stripped of the 

active code and forwarded to the recipient. 

 Spam email and phishing attempts may be deleted or tagged as suspicious. 

 Extra-large files might be held for delivery during off-peak hours. 

Another key feature of content filtering packages is the scanning of outbound data. A lexical 

analysis can be performed that scans email messages for words and phrases that might be viewed 

as inappropriate for use in organizational email. The lexical analysis can also save possible 

litigation against an organization by preventing inappropriate content, including hoaxes and spam 

(see Section 6.3), from leaving the organization. In addition, a lexical analysis might include 

searches for key words and phrases indicating that sensitive data is leaving the enterprise. 

Organizations should also take steps to prevent email address spoofing, such as ensuring that 

external users cannot send emails to internal users that have one of the organization’s email 

addresses as the spoofed sender. For example, a hypothetical company WidgetsRUs should block 

any incoming email with a “from” address in the domain widgetsrus.com at its email gateway. 

Attackers often spoof email addresses to make their malicious emails appear to be from internal 

users, because it can trick users into trusting the emails. Checking digital signatures on emails is 

a way that users can detect some spoofing attempts. 

Before implementing any filtering solution, it is imperative to determine how the existing 

network and applications actually work. This will entail running network analyzers (sniffers); 

analyzing router, firewall, and server log files; and interviewing all appropriate system and 

network administrators. It is also imperative to analyze the existing organization information 

system security policy, or draft one if one does not exist. Clearly defined security policies are 

critical to translating the organization’s security goals into filter rules. Great care must be taken 

in crafting the rules because an incorrectly configured filter may fail to filter inappropriate 

content or may accidentally filter appropriate content. These steps will make it easier to choose 

the appropriate filtering software and determine the types of rules that need to be configured. 

Another effective way to decrease the number of unwanted messages reaching mail servers is 

using Lightweight Directory Access Protocol (LDAP) lookup on a mail gateway or firewall as a 

filtering mechanism. LDAP lookup allows the gateway or firewall to query the organization’s 

user directory directly for user information. When an email is received by the gateway or 

50 
Guidelines on Electronic Mail Security (Draft) 

firewall, it contacts the user directory to see if the email is addressed to a user that actually exists. 

If the user is not in the directory, the email is rejected and does not reach the mail server. Much 

of the spam sent to a domain is generated using a database of common usernames. Most of these 

addresses do not exist for a particular domain, but it is an easy method for spammers to get their 

messages to many users quickly. Using LDAP lookup prevents these messages from slowing the 

mail server. 

Many Internet service providers (ISP) and third-party companies offer malware scanning and 

content filtering services, including spam filtering. These services can be helpful for 

organizations that wish to add an extra layer of defense but do not want to implement or maintain 

the extra layer of protection themselves. The services delete or tag messages before they reach an 

organization’s mail server, therefore increasing its efficiency. Because these services may 

monitor emails for many organizations, they can often identify new unwanted messages very 

quickly. Disadvantages of using such a service include the following: 

 Privacy. All of the organization’s incoming email is routed through the service provider’s 

servers and scanned by them. 

 False Positives. The service provider’s filtering solution might automatically delete emails 

tagged as spam or might not provide a way for administrators to check the validity of email 

tagging. 

 Availability. If the service becomes unavailable, the organization should be able to change the 

routing of mail to prevent delays in mail delivery. 

6.2.3 Content Filtering Issues 

Although email content filtering is critical to most organizations’ security posture, a number of 

legal implications should be addressed before deployment. Content filtering needs to be backed 

up by a clearly defined written security policy. The email policy should include an explicit 

statement that email will be monitored for compliance, a description of any administrative or 

disciplinary actions that could result if the policy is violated, and a requirement for employees to 

acknowledge reading and understanding the policy. Although the policy should outline the 

organization’s thinking, expectations, and restrictions regarding security, due regard should also 

be given to employee and individual rights. For instance, under some circumstances employees 

may have a right to privacy when it comes to their own correspondence; however, when 

representing their organization, the organization may be held legally responsible for what they 

say or do. Without an established policy, such issues often lead to misunderstanding and 

problems that can be difficult to resolve. 

Similarly, in some situations, email messages may be deemed to carry the same legal weight as 

written documents, especially when digitally signed. This can mean having to store messages to 

comply with record-keeping requirements, including employees’ personal messages. As such, all 

employees should be made aware of the security policy. To the extent possible, the security 

policy should be broadly distributed to employees [PCMAG01]. Moreover, it may be advisable 

to require employees to acknowledge the policy as part of their contract of employment or as a 

condition of working on a contract, and to also require employees to re-acknowledge the policy 

on a regular basis. Many email filter applications can add a legal disclaimer to all incoming and 

outgoing messages, ensuring recipients understand the legal weight (or lack thereof) of the emails 

received from or through the organization. 

51 
Guidelines on Electronic Mail Security (Draft) 

Appropriate legal, privacy, personnel, and human resources authorities should be consulted when 

forming the policy. Inevitably, this means having the policy reviewed by experts to ensure that it 

is legally correct and does not infringe upon the rights of employees. Additionally, it is important 

to investigate all areas of an organization to determine how workers go about their work and what 

level of security is most appropriate. Completely restricting access to Internet resources might 

solve most security issues at a stroke, but this is usually an unacceptable tradeoff. This is where 

email filtering tools can help, enabling security policies to be more easily converted from theory 

into practice. 

As previously mentioned, personal email accounts are problematic, especially those accessed via 

a Web browser that tend to bypass the email content filtering controls. In particular, if a user is 

using an SSL-encrypted Web page for personal email access and the organization does not 

decrypt and analyze SSL-encrypted HTTPS traffic, the content may be allowed out or in even 

though it would not be if it went through normal channels. Many organizations also allow 

encrypted protocols outbound (e.g., from their internal network to the Internet) such as SSH or 

IPsec that can also be used to tunnel traffic in or out of the organization without the restrictions of 

filtering. 

If an organization allows mail protocols, such as SMTP, outbound to the Internet for all internal 

users, content filtering may be bypassed by users setting up their own mail servers. 

Organizations should be aware that certain products and applications use SMTP mail for 

communications. It is not uncommon in large organizations for a significant percentage of the 

outbound mail traffic to be generated by servers other than the centralized enterprise mail servers. 

Often these emails are generated from electronic commerce applications communicating with 

customers or business partners. One way to address the problem is to set up a mail gateway or 

application proxy at the perimeter that does content filtering on all email, even those messages 

generated by or destined to servers other than the centralized enterprise mail servers. Section 7 

provides additional information on network architectures and mail gateway placements. 

6.3 Blocking Spam-Sending Servers 

Regardless of the communication medium, there are always entities that attempt to exploit any 

means of communication to publicize their ideas or products. Email is no exception. The most 

common terms for these messages are unsolicited commercial email (UCE), which is better 

known as spam. Most email users receive spam on a daily basis. Because email is largely 

unregulated, system administrators should police email traffic that traverses the servers they 

operate to reduce the amount of spam that reaches users. An added benefit of implementing 

server-based spam control is that it will reduce mailbox sizes, which in turn reduces server 

storage requirements.35 

To control spam messages, administrators must address three concerns: (1) ensure that spam 

cannot be sent from the mail servers they control (see Section 6.4); (2) implement spam filtering 

for inbound messages (see Section 6.2); and (3) block messages from known spam-sending 

servers, which is the topic of this section. 

 

35 For more information on spam, see RFC 2505, Anti-Spam Recommendations for SMTP MTAs

(http://ietf.org/rfc/rfc2505.txt). 

52 
Guidelines on Electronic Mail Security (Draft) 

Because the Internet has no centralized policing authority, non-profit organizations and 

commercial companies have created lists of mail servers that have been identified as being used 

to send unsolicited email messages. These lists are often referred to as open relay blacklists 

(ORB) or DNS blacklists (DNSBL). Many popular mail server applications can be configured to 

query multiple ORBs and reject messages originating from the listed mail servers. These lists are 

updated on a daily basis; therefore, using them can drastically reduce spam message delivery. 

Additionally, most mail servers can be configured to reject messages from an explicitly defined 

set of domains. 

ORB spam control is not foolproof. Open relays are connected and disconnected regularly. Mail 

server administrators who wish to participate in the policing effort may submit UCE complaints 

to Web sites provided in Appendix E: Spam Resources. 

6.4 Authenticated Mail Relay 

As mentioned previously, configuring mail relay authentication decreases the likelihood of 

someone using a particular mail server to send spam. An added benefit of implementing 

authenticated relay is increased security and usability. 

Two methods are available for controlling mail relay. The first is to control the subnet or domain 

from which messages are being sent. This method is effective if the perimeter of the messaging 

system resides within known address ranges. However, if remote users have systems with 

different address ranges, this method is not useful. To accommodate remote users, a more robust 

configuration is needed. 

The second method is to require users to authenticate themselves before sending any messages. 

This is commonly referred to as authenticated relay, or SMTP AUTH, which is the SMTP 

extension that supports user authentication. Unfortunately, the default configuration of most mail 

servers does not implement authenticated relay; therefore, mail server administrators must 

configure the server appropriately. Requiring authenticated relay is one of the least used but most 

powerful security features of mail servers. (Refer to manufacturer documentation for configuring 

SMTP AUTH.) 

Mail server administrators must use caution if choosing to have an authenticated relay. An 

improperly configured mail server could be exploited and used to send or relay spam. If the mail 

server is found to be an open relay, it might be put on a blacklist (as described in Section 6.3). 

Any organizations subscribing to and using these blacklists will not be able to receive any email 

from a blacklisted server, whether the messages are spam or valid emails. 

If a mail server administrator learns that one of his or her mail servers is on a blacklist, the 

administrator will have to fix the open relay problem and perform testing to ensure the server is 

no longer relaying. The administrator then needs to determine which blacklists the server is on 

and check with each blacklist maintainer to get instructions on how to remove the server from the 

lists. Until the server has been removed from all blacklists and the updated blacklists have been 

propagated to their subscribers, outbound email from the organization may not reach all of its 

recipients. See Appendix D for a listing of Web sites that provide open relay testing tools as well 

as the maintainers of commonly used blacklists. 

53 
Guidelines on Electronic Mail Security (Draft) 

6.5 Secure Access 

In Section 2, different mail transport and mailbox access protocols were discussed. Like many 

Internet protocols, most of these protocols did not initially incorporate any form of encryption or 

cryptographic authentication. These deficits posed three problems for mail users. First, for users 

sending messages, the contents could be intercepted and read at any host on the path between the 

sender and recipient or even forged or modified. An apt paradigm from “regular” mail would be 

a postcard. Any person who handles the postcard can read the message on the back. Second, the 

recipients cannot verify that messages were actually originated by the sender or unmodified by 

others when in transit. These problems were addressed in Section 3, which discussed ways to 

protect messages. Third, rather than supplying non-reusable authentication information, a user 

accessing a mailbox would send a password over the network in the clear, which could be easily 

observed and reused by an attacker. Unfortunately, in most default configurations, mail clients 

are set up to send the user’s password in the clear, allowing it to be intercepted by other 

computers on the local network segment of the client or any host responsible for forwarding the 

password to the mail server. 

This last problem can be resolved by applying the same method normally used to secure World 

Wide Web (WWW) traffic – the Transport Layer Security (TLS) protocol. TLS is similar to the 

Secure Sockets Layer (SSL) protocol, upon which it is based, and can be used in combination 

with POP, IMAP, and SMTP to encrypt communication between mail clients and servers. RFC 

2595 defines how to use TLS to combat communications eavesdropping, to implement secure 

mailbox access and to further strengthen SMTP MTAs that incorporate SMTP AUTH. Figure 6.4 

shows a sample configuration that enables TLS support for newer versions of sendmail. 

define(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')dnl 

define(`confCACERT_PATH', `CERT_DIR')dnl 

define(`confCACERT', `CERT_DIR/CAcert.pem')dnl 

define(`confSERVER_CERT', `CERT_DIR/MYcert.pem')dnl 

define(`confSERVER_KEY', `CERT_DIR/MYkey.pem')dnl 

define(`confCLIENT_CERT', `CERT_DIR/cert.pem')dnl 

define(`confCLIENT_KEY', `CERT_DIR/MYkey.pem')dnl 

Figure 6.4: Sendmail TLS Configuration Example from sendmail.mc 

54 
Guidelines on Electronic Mail Security (Draft) 

6.6 Enabling Web Access 

Increasingly, organizations are providing Web browser-based access to their messaging systems. 

Enabling this type of access could introduce security issues at both the client (see Section 8.4) 

and server. Although Web site security is outside the scope of this document, there are several 

key concepts that should be followed. Avoid placing the Web server on the same machine as the 

mail server. The authentication mechanism of the Web front-end should employ encryption. The 

Web server should use SSL/TLS to encrypt all communications with clients. For some 

organizations, the processing requirements of dedicating a Web server to SSL/TLS 

communication may not be possible to accommodate. In cases such as this, the initial 

authentication should be encrypted. As with any public server, the Web server should be 

hardened before connecting it to the network.36

Some organizations choose to use hardware appliances for their Web access solution. These 

appliances not only provide secure Web-based access to mail servers, but they also provide 

firewall, content filtering, and malware protection capabilities. The appliances typically are 

easier and faster to install and maintain than creating Web servers, and they often use hardened 

operating systems with all non-essential components disabled or removed, which limits the 

possible vulnerabilities the appliances might have. Some appliances offer additional capabilities, 

such as offering administrators granular control over user groups and access, performing SSL 

encryption for sessions, and terminating user sessions automatically after a period of inactivity. 

Appliances are available that support the most commonly used Web-based mail systems. 

Client security issues exist that also need to be considered before an organization approves the 

deployment of Web access to email. These issues are discussed in Section 8.4. 

 

36 For more information on securing Web servers, please refer to NIST SP 800-44, Securing Public Web Servers 

(http://csrc.nist.gov/publications/nistpubs/index.html). 

55 
Guidelines on Electronic Mail Security (Draft) 

6.7 Mail Server and Content Security Checklist 

Completed Action

Hardening the mail server application 

Install the mail server software on a dedicated host 

Apply any patches or upgrades to correct for known 

vulnerabilities 

Create a dedicated physical disk or logical partition (separate from 

operating system and mail server application) for mailboxes, or 

host the mailboxes on a separate server 

Remove or disable all services installed by the mail server 

application but not required (e.g., Web-based mail, FTP, remote 

administration) 

Remove all manufacturer documentation from server 

Remove any example or test files from server 

Apply appropriate security template or hardening script to the 

server 

Reconfigure SMTP, POP and IMAP service banners (and others 

as required) NOT to report mail server and operating system type 

and version 

Disable dangerous or unnecessary mail commands (e.g., VRFY 

and EXPN)

Configuring operating system and mail server access controls 

Limit the access of the mail server application to a subset of 

computational resources 

Limit the access of users through additional access controls 

enforced by the mail server, where more detailed levels of access 

control are required 

Configure the mail server application to execute only under a 

unique individual user and group identity with restrictive access 

controls 

Ensure the mail server is not running with root or 

system/administrator privileges 

Configure the host operating system so that mail server can write 

log files but not read them 

Configure the host operating system so that temporary files 

created by mail server application are restricted to a specified and 

appropriately protected subdirectory 

Configure the host operating system so that access to any 

temporary files created by the mail server application is limited to 

the mail server processes that created these files 

Ensure that the mail server cannot save files outside of the 

specified files structure dedicated to the mail server 

56 
Guidelines on Electronic Mail Security (Draft) 

Completed Action

Configure the mail server to run in a chroot jail on Linux and Unix 

hosts 

Install users’ mailboxes on a different server (preferred), hard 

drive, or logical partition than the operating system and mail 

server application 

Limit the size of attachments that are allowed 

Ensure log files are stored in a location that is sized appropriately 

Coping with harmful attachments and content 

Implement centralized malware scanning (on the firewall/mail 

relay/mail gateway and/or mail server, preferably both) 

Install malware scanners on all client hosts 

Update the signature databases of all malware scanning software 

on a daily basis or when there is a malware outbreak 

Educate users on the dangers of malware and how to minimize 

those dangers 

Notify users when an outbreak occurs 

Configure content filtering to block or tag suspicious messages 

(e.g., phishing, spam) 

Configure content filtering to strip suspicious active content from 

messages 

Configure lexical analysis if required 

Create a content filtering policy 

Add a legal disclaimer to emails, if required 

Configure mail gateways or firewalls to use LDAP lookup to 

confirm the existence of email recipients 

Configure mail server to block mail from open relay blacklists or 

DNS blacklists 

Configure mail server to block mail from specific domains, if 

required 

Configure authenticated mail relay on server 

Configure mail server to use encrypted authentication 

Configure mail server to support Web access only via SSL/TLS 

and only if such access is deemed necessary 

57 
Guidelines on Electronic Mail Security (Draft) 

7. Implementing a Secure Network for a Mail Server 

The network infrastructure that supports the mail server plays a critical role in the security of the 

mail server. In most configurations, the network infrastructure is the first line of defense between 

the Internet and a mail server. Network design alone, however, cannot protect a mail server. The 

frequency, sophistication, and variety of attacks perpetrated today lend support to the idea that 

mail security must be implemented through layered and diverse protection mechanisms (layered 

protection). This section discusses those network components that can support and protect mail 

servers to further enhance their overall security. While security issues are paramount, network 

infrastructure considerations are influenced by many factors other than security, including cost, 

performance, and reliability. 

7.1 Network Composition and Structure 

Firewalls and routers are devices or systems that control the flow of network traffic between 

networks. They can protect mail servers from vulnerabilities inherent in the Transmission 

Control Protocol/Internet Protocol (TCP/IP) suite and help reduce the security issues associated 

with insecure applications and operating systems. However, an organization has many choices 

when determining a network environment for the mail server, and security may not be the 

principal factor in deciding among those options. Network composition and structure are the first 

and in many respects the most critical decisions that affect mail server security, since they 

determine what network infrastructure elements protect the mail server. For example, if the mail 

server is located before the organization’s main firewall, then the firewall cannot be used to 

control traffic to and from the mail server. Network composition and structure also determine 

what other portions of the network are vulnerable if the mail server is compromised. For 

example, an externally accessible mail server located on the internal production network subjects 

the internal network to attack if the mail server is compromised. 

7.1.1 Inadvisable Network Layout 

Some organizations choose to locate their public mail servers on their internal production 

networks. That is, their mail servers reside on the same network as the internal users and servers. 

The principal weakness of this layout is that it exposes internal network components to additional 

risks. Mail servers are often targets of attackers. If attackers manage to compromise a mail 

server, they will have access to the internal network and be able to more easily compromise 

internal hosts. Therefore, this layout is not recommended. 

Another network layout that is not generally recommended is placing the mail server before an 

organization’s firewall or router that provides IP filtering. In this structure, the network provides 

little, if any, protection for the mail server. Because the mail server itself has to maintain 

security, it provides a single point of failure. To be even somewhat secure in this location, the 

mail server operating system and application have to be well-hardened, with all unnecessary and 

insecure services disabled and all necessary security patches applied. To maintain the “security” 

of the setup, the mail server administrator must stay up-to-date on vulnerabilities and related 

patches. Another limitation of this structure is that providing any sort of secure remote 

administration capability is difficult. 

58 
Guidelines on Electronic Mail Security (Draft) 

7.1.2 Demilitarized Zone 

A demilitarized zone (DMZ) describes a host or network segment inserted as a “neutral zone” 

between an organization’s private network and the Internet. It prevents outside users of the mail 

server from gaining direct access to an organization’s internal network (intranet). A DMZ 

mitigates the risks of locating a mail server on an internal network or exposing it directly to the 

Internet. It is a compromise solution that offers the most benefits with the least amount of risk for 

most organizations. The DMZ allows access to the resources located within it to both internal 

and external users. There are a wide variety of DMZ configurations, each with its own strengths 

and weaknesses. 

Creating a DMZ involves placing a firewall between an organization’s border router and its 

internal network, and creating a new network segment that can only be reached through the DMZ 

device. The mail server or mail gateway is placed on the new segment, along with other network 

infrastructure components and servers that need to be externally accessible. For example, if Webbased mail access is offered, the associated servers are typically placed on the DMZ. In some 

configurations, the border router itself may act as a basic firewall. Figure 7.1 illustrates an 

example of this simple DMZ using a router with access control lists (ACL) to restrict certain 

types of network traffic to and from the DMZ. 

Figure 7.1: Simple Single-Firewall DMZ

A single-firewall DMZ is a low-cost approach, since the organization needs only to add a single 

firewall and use its existing border router to provide protection to the DMZ. It is usually 

appropriate only for small organizations that face a minimal threat. The basic weakness in the 

approach is that while the router is able to protect against most network attacks, it is not “aware” 

of the mail server application layer protocols (e.g., SMTP, POP, IMAP) and thus cannot protect 

against application layer attacks aimed at the mail server. In addition, a router cannot provide any 

virus scanning of incoming email. A superior approach is to add a second firewall between the 

Internet and the DMZ, as shown in Figure 7.2. 

59 
Guidelines on Electronic Mail Security (Draft) 

Figure 7.2: Two-Firewall DMZ 

A two-firewall DMZ configuration improves protection over a router-firewall DMZ, since the 

dedicated firewalls can have more complex and powerful security rule sets. In addition, because 

a dedicated firewall is often able to analyze incoming and outgoing mail traffic, it can detect and 

defend against application layer attacks aimed at the mail server. Depending on the rule sets of 

the firewalls and the level of traffic the DMZ receives, this type of DMZ may result in some 

performance degradation. 

For organizations that desire the security of the two-firewall DMZ, but do not have the resources 

to purchase two firewalls, another option exists called the “service leg” DMZ. In this 

configuration, a firewall is constructed with three (or more) network interfaces. One network 

interface attaches to the border router, another interface attaches to the internal network, and a 

third interface connects to the DMZ (see Figure 7.3). 

Figure 7.3: Three Interface Firewall DMZ

This configuration subjects the firewall to an increased risk of service degradation during a DoS 

attack aimed at the DMZ. In the standard single-firewall DMZ network configuration discussed 

60 
Guidelines on Electronic Mail Security (Draft) 

above, a DoS attack against the mail server generally affects only the mail server. In a serviceleg DMZ network configuration, the firewall bears the brunt of any DoS attack because it must 

examine any network traffic before the traffic reaches the mail server (or any other DMZ or 

internal network resource) [NIST02a]. However, it is increasingly likely that a DoS attack will 

take the form of a distributed denial of service (DDoS) attack and consume all of the incoming 

network bandwidth and related devices (e.g., Internet border routers) before ever reaching a DMZ 

firewall. 

The advantages of a DMZ from a security standpoint are as follows: 

 The mail server may be better protected, and network traffic to and from the mail server can be 

monitored. 

 Compromise of the mail server does not directly threaten the internal production network. 

 Greater control can be provided over the security of the mail server since traffic to and from 

the mail server can be controlled. 

 The DMZ network configuration can be optimized to support and protect the mail servers. 

The disadvantages of a DMZ from a security standpoint are as follows: 

 DoS attacks aimed at the mail server may have an effect on the internal network. 

 Depending on the firewall configuration controlling traffic between the DMZ and internal 

network, it may be possible for the mail server to be used to attack or compromise hosts on the 

internal network. In other words, protection offered by the DMZ depends in large part on the 

firewall configuration. 

7.1.3 Mail Gateways 

Using a mail gateway in the DMZ adds further protection for a mail server. The additional layer 

makes the mail server significantly more difficult to attack. When a mail server is located in the 

DMZ, it still must communicate with untrusted third parties, which provides an avenue for 

attackers. A mail gateway acts as a proxy between the real mail server and the Internet. All 

messages and communications must go through the proxy before they are forwarded to the mail 

server. Breaking the direct line of communication between the Internet and the mail server makes 

it much more difficult to attack the mail server. Since the mail gateway generally requires only 

limited functionality, it is much easier to harden and secure than a fully functional mail server. 

Figure 7.4 provides an example of using a mail gateway to fortify a mail server on the internal 

network. 

61 
Guidelines on Electronic Mail Security (Draft) 

Figure 7.4: Mail Gateway 

7.1.4 Management Network 

Mail servers, gateways, and other important components can be connected to each other and 

managed through an organization’s standard networks or through a separate network known as a 

management network. If a management network is used, each host being managed through the 

network has an additional network interface known as a management interface that connects to 

the management network. Also, each host being managed is unable to pass any traffic between 

its management interface and any of its other network interfaces. Consoles and other hosts that 

are used to manage the mail components are attached to the management network only. This 

architecture effectively isolates the management network from the production networks. The 

benefits of doing this are to protect the components from some attacks and to ensure that the 

components can be managed under adverse conditions (e.g., widespread mail-borne malware 

infection). Disadvantages of using a management network include the additional costs in 

networking equipment and other hardware (e.g., PCs for the consoles) and the inconvenience for 

mail component administrators of using separate computers for management and monitoring. 

7.2 Network Element Configuration 

Once the mail server has been positioned in the network, the network infrastructure elements 

should be configured to support and protect it. The elements of a network infrastructure that 

affect mail server security are firewalls, routers, intrusion detection systems (IDS), intrusion 

prevention systems (IPS), and switches. Each has an important role to play and is critical to the 

overall strategy of protecting the mail server through layered protection. Unfortunately, when it 

comes to securing a mail server, there is no single “silver bullet” solution. A firewall or IPS 

alone cannot adequately protect a mail server from all threats or attacks. 

7.2.1 Router/Firewall Configuration 

Several types of firewalls exist. The most basic ones are routers that can provide access control 

on IP packets. In the middle are stateful firewalls that can provide access control based on TCP 

62 
Guidelines on Electronic Mail Security (Draft) 

and User Datagram Protocol (UDP) as well as IP. The most powerful firewalls are application 

layer or proxy firewalls that are able to understand and filter mail content and commands.37 

A common misperception about firewalls and routers (acting as firewalls) is that they eliminate 

all risk and can protect against the misconfiguration of the mail server or poor network design. 

Unfortunately, this is not the case. Firewalls and routers themselves are vulnerable to 

misconfiguration and software vulnerabilities. In addition, most firewalls have limited or no 

“insight” into the application layer where many current attacks occur. Thus mail servers in 

particular are vulnerable to many attacks, even when located behind a secure, well-configured 

firewall. 

A firewall or router (acting as a firewall) that is protecting a mail server should be configured to 

block all access to the mail server from the Internet except the necessary ports, such as TCP port 

25 (SMTP). A firewall is the first line of defense for a mail server; however, to be truly secure, 

organizations need to implement layered protection for their mail servers (and networks). Most 

importantly, organizations should strive to maintain all systems in a secure posture and not 

depend solely on routers, firewalls, or any other single component to stop attackers. 

A modern enterprise router is able to function as a network and transport layer filter (e.g., a basic 

firewall). A router functioning as a network/transport layer firewall can provide filtering based 

on several pieces of information [NIST02a], including the following: 

 Source IP address 

 Destination IP address 

 Traffic type 

 TCP/UDP port number and state. 

The strengths of routers are in the following areas: 

 Cost (most organizations already have a border router that can be configured to provide 

network/transport layer firewall capabilities). 

The weaknesses of routers are in the following areas: 

 Susceptibility to application layer attacks (e.g., cannot examine mail content or commands) 

 Susceptibility to attacks via allowed ports 

 Difficulty of configuration and administration 

 Limitations in logging capabilities 

 Processing capabilities may be more limited and overtaxed by complex rule sets (i.e., access 

controls lists) 

 

37 For more information about firewalls, see NIST SP 800-41, Guide to Firewall Selection and Policy 

Recommendations, (http://csrc.nist.gov/publications/nistpubs/index.html). 

63 
Guidelines on Electronic Mail Security (Draft) 

 Insufficient rule set expressiveness and filtering capabilities. 

The only “pure” network layer firewalls available today are small office/home office (SOHO) 

firewall appliances and personal firewalls [NIST02a] that may only perform basic packet-level 

filtering. 

Stateful inspection firewalls are transport layer devices that incorporate “awareness” of the state 

of a TCP connection. Stateful inspection firewalls maintain internal information such as the state 

of the connections passing through and the contents of some of the data streams. This allows 

better and more accurate rule sets and filtering to be specified. Stateful inspection firewalls add 

the capability to enforce rules based on connection state to the capabilities of a filtering router. 

Application layer firewalls (sometimes called application-proxy gateway firewalls) are advanced 

firewalls that combine network and transport layer access control with application layer 

functionality. Application layer firewalls permit no traffic directly between the Internet and the 

internal network, or between two networks. They can usually perform extensive logging and 

access control. 

Application layer firewalls are considered the most secure type of firewall and have numerous 

advantages over packet filtering routers and stateful inspection firewalls, including the following 

areas: 

 Logging capabilities 

 Filtering capabilities (can filter specific types of mail content and specific SMTP, POP, and 

IMAP commands) 

 Ease of configuration 

 User authentication capabilities. 

The primary disadvantages that application layer firewalls have when compared to packet 

filtering routers and stateful inspection firewalls are as follows: 

 Speed of throughput. 

 Cost (if high end hardware is required to operate effectively) 

 Support for less popular and new protocols. 

Although not strictly a limitation, application layer firewalls are sometimes implemented on hosts 

running general-purpose operating systems (e.g., Windows, Linux, Unix). This arrangement 

introduces an added layer of complexity because that general-purpose operating system must also 

be secured in addition to the firewall software itself. Application layer firewalls are increasingly 

being deployed as appliance-based devices, which may use specialized operating systems. 

Routers and stateful inspection firewalls also typically run on specialized operating systems. 

To successfully protect a mail server using a firewall, ensure that the firewall is patched to the 

latest or most secure level (application and underlying operating system) and is both capable of 

and configured to support the following items: 

64 
Guidelines on Electronic Mail Security (Draft) 

 Control all traffic between the Internet and the mail server 

 Block all inbound traffic to the mail server except that traffic which is required, such as TCP 

port 25 (SMTP). 

 Block (in conjunction with the intrusion detection or prevention system [see Section 7.2.2]) IP 

addresses or subnets that the IDS or IPS reports are attacking the organizational network 

 Block known “blacklisted” networks or subnets as identified by a trusted external security 

response center 

 Notify the network or mail server administrator of suspicious activity through an appropriate 

means (e.g., page, email, network trap) 

 Provide content filtering 

 Provide malware scanning 

 Protect against DoS attacks 

 Log critical events, including the following details: 

 Time/date 

 Interface IP address 

 Manufacturer-specific event name 

 Standard attack event (if one exists) 

 Source and destination IP addresses 

 Source and destination port numbers 

 Network protocol. 

Most firewall devices available in hardware and software perform some type of logging of the 

traffic they receive. For most firewalls, the default logging configuration is suitable, provided 

logging is enabled. Administrators should consult their manufacturer documentation if they 

believe they require additional information to be logged. Certain brands of hardware-based 

firewalls include an ability to track and log information for each rule. This ability enables 

accountability to a very specific extent. 

Many firewalls support the ability to selectively decide what information to log. If a firewall 

receives a series of similar packets from the same location, it may decide not to log any additional 

packets after the first one. Although this is a valuable feature, consider the consequences: each 

packet that is dropped and not logged is potential evidence of malicious intent. The principle of 

logging, a fundamental aspect of accountability, is discussed in detail in Section 9.1. 

65 
Guidelines on Electronic Mail Security (Draft) 

As with operating systems and other security-enforcing elements, a firewall requires updates. 

Although more prevalent in software implementations of firewall technology, hardware and 

router firewalls are capable of updating their firmware. Specific instructions on how to update a 

firewall are found within the manufacturer documentation. Administrators should check for 

firewall updates frequently. 

7.2.2 Intrusion Detection and Prevention Systems 

An intrusion detection system (IDS) is an application that monitors the events occurring in a 

system or network and analyzes them for signs of potential incidents, which are violations or 

imminent threats of violation of computer security policies, acceptable use policies, or standard 

security practices.38 An intrusion prevention system (IPS) has all the capabilities of an IDS and 

can also attempt to stop potential incidents. Because IDS and IPS systems offer many of the 

same capabilities, they are often collectively called intrusion detection and prevention (IDP) 

systems. When an IDP system detects a potential incident, it notifies administrators through IDP 

console messages, emails, pages, or other mechanisms. 

The two types of IDPs most relevant for email security are host-based and network-based.39 A 

host-based IDP monitors the characteristics of a single host and the events occurring within that 

host to identify and stop suspicious activity. Host-based IDP software must be installed on each 

individual computer that is to be monitored or protected. Host-based IDPs are very closely 

integrated with the operating system of the host computer they protect. Thus, a host-based IDP 

must be designed specifically for each operating system (and often each version of that operating 

system). Host-based IDPs monitor various aspects of hosts, such as network traffic, system logs, 

running processes, file access and modification, and system and application configuration 

changes. 

Host-based IDPs are especially useful when most of the network traffic to and from the mail 

server is encrypted (e.g., SSL/TLS or S/MIME is in use) because the functionality and capability 

of network-based IDPs (see below) is severely limited when network traffic is encrypted. Also, 

because they are located on the server, host-based IDPs can detect some attacks and penetration 

attempts not recognized by network-based IDPs. Unfortunately, host-based IDPs can have a 

negative impact on host performance. In general, enabling more extensive detection capabilities 

and having more events to monitor cause a greater negative impact on the performance of the 

host. Host-based IDPs may not detect some network-based attacks such as certain DoS attacks 

[NIST01]. If a host-based IDP is on a mail server that is compromised, it is very likely that the 

attacker will also compromise the IDP itself and vice versa. 

A network-based IDP monitors network traffic for particular network segments or network 

devices and analyzes the network and application protocol activity to identify and stop suspicious 

activity. Most network-based IDPs use predefined “attack signatures” to detect and identify 

attacks. Attack signatures are patterns that correspond to known types of intrusions. Network-

 

38 For more information on IDSs, see NIST SP 800-31, Intrusion Detection Systems,

(http://csrc.nist.gov/publications/nistpubs/index.html). 

39 Other major IDP categories include wireless IDP, which examines wireless networking protocols only, and network 

behavior anomaly detection software, which monitors network traffic flows for flow anomalies. Neither of these types 

of IDP technologies analyzes email activity. 

66 
Guidelines on Electronic Mail Security (Draft) 

based IDPs also use other detection methods to identify anomalous activity, protocol violations, 

and other unusual activity. 

Unlike a host-based IDP, a network-based IDP can monitor network activity for many hosts 

simultaneously. Network-based IDPs can usually detect more network-based attacks and can 

more easily provide a comprehensive picture of the current attacks against a network. Since 

network-based IDPs are installed on dedicated hosts, they do not have a negative effect on the 

performance of the mail server host and are not immediately compromised by a successful attack 

on the mail server. 

Network-based IDPs do have some limitations. The timing of an attack can have a significant 

effect on the ability of a network-based IDP to detect an attack. For example, if an attacker 

spreads out the timing of his attack over a period of hours or days, the attack may not be detected 

by the IDP. Network configuration, such as the use of asymmetric routing, can have a negative 

effect on the ability of a network-based IDP to detect attacks. Network-based IDPs are also more 

susceptible to being disabled by DoS attacks (even those not directly targeted at the IDP). Also, 

depending on how the network-based IDP is integrated into the network, it is possible to 

negatively impact the availability of the network in the event of an IDP hardware failure. 

Most host-based and network-based IDPs require frequent updates to their attack signature 

databases so that they can recognize new attacks. An IDP that is not updated frequently will fail 

to recognize the latest (and often most popular) attacks. Both types of IDPs may be limited in 

their ability to detect zero-day attacks because it is unlikely that an appropriate signature is 

available. A host-based IDP may have a better chance of detecting a zero-day attack since it is 

better able to detect the actions taken by an attacker after a successful exploit (e.g., new 

unauthorized privileged accounts, installation of malicious software). 

File integrity checkers are a simple form of host-based IDP. A file integrity checker computes 

and stores a hash for every guarded file and establishes a database of file hashes. It provides a 

tool for system administrators to recognize changes to files, particularly unauthorized changes. 

File integrity checkers are available both as standalone products and bundled with other hostbased IDP techniques. Some host-based IDPs can monitor file access attempts and stop 

suspicious attempts to read, modify, delete, and execute files. A host-based IDP with this 

capability could be configured to protect important mail server files. 

To successfully protect a mail server using an IDP, ensure that the IDP is capable of and 

configured to: 

 Monitor network traffic to and from the mail server 

 Monitor changes to critical files on the mail server (file integrity checking capability)40

 Monitor the system resources available on the mail server host (host-based) 

 Block (in conjunction with the firewall) IP addresses or subnets that are attacking the 

organizational network 

 

40 Certain critical files, such as files storing user passwords and log files, will change regularly and thus should not be 

protected by a file integrity checker. This will vary depending on the mail server and operating system employed. 

67 
Guidelines on Electronic Mail Security (Draft) 

 Notify the appropriate parties (e.g., IDP administrator, mail server administrator, incident 

response team) of suspected attacks through appropriate means according to the organizational 

incident response policy and procedures 

 Detect as wide a variety of scanning and attacks as possible with an acceptable level of false 

positives 

 Log events, including the following details: 

 Time/date 

 Sensor IP address 

 Manufacturer specific attack name 

 Standard attack name (if one exists) 

 Source and destination IP addresses 

 Source and destination port numbers 

 Network protocol. 

 For network events, packet header information should be captured to assist with the analysis 

and forensics process 

 Update with new attack signatures frequently (e.g., on a daily to weekly basis, typically after 

testing the updates). 

In addition, it is critical that network-based IDPs and their underlying operating systems are 

hardened, as network-based IDPs are often a target of attackers. In particular, the network-based 

IDPs should not respond to any type of system interrogation through their monitoring interfaces. 

If remote management is desired, it should be conducted through an out-of-band means (e.g., 

separate isolated network). Although typically difficult to administer and interpret, IDPs are a 

critical early warning system that can provide the mail server administrator with the necessary 

information to defend the mail server from attack. 

7.2.3 Network Switches 

Network switches are devices that provide connectivity between two or more hosts located on the 

same network segments. They are similar to hubs in that they allow communications between 

hosts, but unlike hubs the switches have more “intelligence” and send communications to only 

those hosts to which the communications are addressed. The benefit of this from a security 

standpoint is that when switches are employed on a network, it is much more difficult to 

eavesdrop on communications between other hosts on the network segment. This is extremely 

important when a mail server is on a network segment that is used by other hosts. For example, if 

a hub is used and a host on the DMZ is compromised, an attacker may be able to eavesdrop on 

the communications of other hosts on the DMZ, possibly leading to the compromise of those 

hosts or the information they communicate across the network. A primary example of this is 

68 
Guidelines on Electronic Mail Security (Draft) 

public Web servers, which are often on the same subnet as mail servers and, if compromised, 

would be able to sniff unencrypted mail traffic and passwords within the DMZ. 

Many switches include specific security settings that further enhance the security of the network 

by making it difficult for a malicious entity to “defeat” the switch. Some examples include the 

ability to minimize the risk of Address Resolution Protocol (ARP) spoofing and ARP poisoning 

attacks.41 If a switch has these security capabilities, they should be enabled (see appropriate 

manufacturer documentation). 

Switches can have a negative impact on network-based IDPs (see Section 7.2.2). Most network 

switches allow network administrators to configure a specific port on the switch, known as a span 

port, so that it replicates all the switch’s traffic to the port used by the IPS. This allows a 

network-based IPS to see all traffic on a particular network segment. However, under high loads, 

the switch might have to stop sending traffic to the span port, causing the IDP to be unable to 

monitor network activity. Also, other devices also use span ports, and there are typically very 

few span ports on a switch, so it might not be possible to connect an IDP to a particular switch 

because its span ports are all being used. 

7.3 Network Infrastructure Checklist 

Completed Action

Network location 

Mail server is located on the internal network and protected by a 

mail gateway and/or firewall, or 

Mail server is located in a DMZ 

Firewall configuration 

Mail server is protected by a firewall 

Mail server, if it faces a higher threat or if it is more vulnerable, is 

protected by an application layer firewall 

Firewall controls all traffic between the Internet and the mail 

server 

Firewall blocks all inbound traffic to the mail server except TCP 

ports 25 (SMTP), 110 (POP3), 143 (IMAP), 398 (LDAP), and 

636 (secure LDAP), if required 

Firewall blocks (in conjunction with the intrusion detection or 

prevention system) IP addresses or subnets that the IPS reports are 

attacking the organizational network 

Firewall notifies the network administrator or mail server 

administrator of suspicious activity through an appropriate means 

Firewall provides content filtering (application layer firewall) 

Firewall is configured to protect against DoS attacks 

 

41 ARP poisoning occurs when an attacker successfully updates the ARP cache on a target host with a forged ARP 

entry. This is generally used to redirect network traffic for malicious purposes. 

69 
Guidelines on Electronic Mail Security (Draft) 

Completed Action

Firewall logs critical events 

Firewall and firewall operating system patched to latest or most 

secure level 

Intrusion detection and prevention systems 

IDP configured to monitor traffic network traffic to and from the 

mail server after firewall 

IDP configured to monitor changes to critical files on mail server 

(host-based IDP or file integrity checker) 

IDP blocks (in conjunction with the firewall) IP addresses or 

subnets that are attacking the organizational network 

IDP notifies the IDP administrator or mail server administrator of 

attacks through appropriate means 

IDP configured to maximize detection with an acceptable level of 

false positives 

IDP configured to log events 

IDP updated with new attack signatures frequently (e.g., on a daily 

basis) 

Host-based IDP configured to monitor the system resources 

available on the mail server host 

Network switches 

Network switches are used to protect against network 

eavesdropping 

Network switches are configured in high-security mode to defeat 

ARP spoofing and ARP poisoning attacks 

Network switches are configured to send all traffic on network 

segment to network-based IDP 

70 
Guidelines on Electronic Mail Security (Draft) 

8. Mail Client Security 

Hundreds to thousands of mail clients access every operational mail server. Regardless of the 

security in place on mail servers, it is important to secure the client side. In many respects, the 

client side represents a greater risk to security than the mail server. Numerous issues need to be 

carefully considered and addressed to provide an appropriate level of security for email clients. 

This section provides general recommendations that apply to most email client applications. 

Specific recommendations for securing particular applications are not included in this document. 

8.1 Securing Installing, Configuring, and Using Client Applications 

8.1.1 Patching and Updating Mail Clients 

The most important step in securing an email client is to ensure that all users are using the latest 

and/or most secure version of the mail client with all necessary patches applied.42 Most major 

email clients have had significant vulnerabilities. To identify the vulnerabilities of a particular 

mail client, see the NIST National Vulnerability Database (NVD) (http://nvd.nist.gov/). The best 

resource for patches is the appropriate manufacturer’s Web site. Appendix E contains a list of 

email client manufacturer Web sites. 

Updating some mail clients is made slightly more complicated because they operate in 

conjunction with Web browsers. For example, the close integration and bundling of Microsoft 

Outlook, a mail client, and Internet Explorer, a Web browser, has allowed the configuration 

settings and vulnerabilities of the latter to affect the former. In such situations, keeping both the 

mail client and Web browser updated to secure versions and patch levels is particularly important. 

Failure to run a secure version of a mail client reduces the effectiveness of the rest of the security 

measures discussed below. 

8.1.2 Configuring Mail Client Security Features 

Mail client applications may not be configured securely in their default configurations. Mail 

clients should be configured to: 

 Disable automatic message preview. 

 Disable automatic opening of messages. 

 Disable automatic loading of pictures in messages. 

 Disable downloading and processing of active content. Examples include ActiveX controls, 

Java applets, and JavaScript. This may cause problems for email applications that are bundled 

with Web browsers, because disabling this functionality could affect the Web browser, where 

such functionality may be required. In those cases, some selective and careful 

disabling/enabling of active content may be needed. In the case of Microsoft Outlook and 

 

42 When and how to apply patches includes many complex issues that are beyond the scope of this document. For a 

more detailed discussion of security patches, see NIST SP 800-40 Version 2.0, Creating a Patch and Vulnerability 

Management Program (http://csrc.nist.gov/publications/nistpubs/index.html). 

71 
Guidelines on Electronic Mail Security (Draft) 

Internet Explorer, separate Security Zones could be defined for each, which would allow 

Internet Explorer to have less restrictive security settings than Outlook. 

 Enable anti-spam and anti-phishing features, if available. These features often have rather 

permissive settings by default, so it may be beneficial from a security perspective to set them 

to a higher level. Also, users should be educated on reviewing tagged or filtered messages to 

identify ones that have been incorrectly labeled. Some mail clients allow users to configure 

filtering features such as creating lists of safe senders and senders to block. 

There are additional issues specific to portable email clients, such as those on cell phones and 

PDAs. The use of portable email clients has increased significantly in recent years. Users should 

be made aware that the information that is stored on them is at risk, and that they need to take the 

necessary precautions in case their devices are lost or stolen. Beyond the obvious physical 

security measures, users should also reconfigure their devices, which are typically configured 

insecurely by default. Security features to consider include the following: 

 Requiring a password or a PIN to gain access to the device. 

 Encrypting locally stored data, including messages and downloaded file attachments. 

 Encrypting and/or signing messages, such as supporting S/MIME or OpenPGP and managing 

digital certificates. 

 Encrypting communications between the email client and the mail server, such as using SSLbased encryption to protect POP, IMAP, and SMTP communications. 

 Remotely rendering the device useless or deleting its information if it is compromised. 

 Changing the Bluetooth discovery PIN number on Bluetooth devices to prevent unauthorized 

access. 

Organizations should also ensure that their security policy supports the protection of portable 

email clients, such as requiring that the devices have anti-virus software enabled on them if 

available and that wireless functionality be turned off when not being used. Organizations that do 

not want certain types of devices used to access email should specify the restriction in their 

security policy. 

Many organizations configure mobile devices with VPN access to corporate networks or 

applications that can connect remotely to servers. As a good security measure, limit access to 

these applications or remove them if they are not being used. Also, do not store logins, 

passwords, or personal information on the devices. If the device is stolen, an attacker could 

potentially use network login information with the VPN to access internal network resources. 

8.1.3 Configuring Authentication and Access 

Early mail client applications did not require user authentication because mailbox access was 

restricted by the local filesystem and the user owned the mailbox file. As MUAs evolved and 

provided the functionality to access mailboxes remotely via POP and IMAP (see Section 2), user 

authentication became a requirement. Typically, this was accomplished with users inputting a 

username and a password when accessing their mailbox. To be more “user-friendly,” mail clients 

incorporated configuration files that contained (e.g., “remembered”) usernames and passwords 

72 
Guidelines on Electronic Mail Security (Draft) 

with which to access the mail server. Although this provides ease of use for users, it introduces 

security weaknesses insofar as a remote or local attacker having logical or physical access to the 

mail client host may gain access to the authentication information and, in turn, the mailbox 

contents. In addition, if automatic completion of user input is enabled, a local attacker may be 

able to use the feature to discover passwords systematically. 

Disabling password recall functionality is an effective way to increase mail client security. If the 

functionality cannot be disabled, then keeping these configuration files secure is important. Most 

operating systems provide file permission and access control features that will offer some means 

of protection. With systems that do provide these controls, ensure that the mail client 

configuration files are restricted for accessibility by only the file owner. Additionally, ensure that 

the file is located in a directory controlled by the owner. In cases where a system’s file 

permissions and access controls are unavailable, the best resolution is to remove the user 

passwords from the configuration files. 

Another area to address is the actual communication between the mail client and mail server. As 

mentioned in Section 3, all network communication with the default configurations of SMTP, 

POP, and IMAP occurs unencrypted. This makes usernames, passwords, and message content 

subject to interception and alteration by malicious entities. To increase client to server security, 

this communication can be encrypted using SSL/TLS. Most commonly used mail clients support 

SSL/TLS; it should be used if it is available. TLS version 1 is preferred for use; at a minimum, 

SSL version 3 should be used.43 

The selection of email addresses and user account names also affects authentication. Using 

account names in email addresses should be avoided, so that an attacker cannot easily determine a 

person’s account name from the person’s email address. Organizations that allow users to select 

their own email account names should put controls in place to ensure that account names and 

email addresses are distinct and unrelated. Organizations might also want to place additional 

restrictions on email addresses, such as having different naming conventions for certain types of 

users (e.g., contractors, foreign nationals) to allow the user type to be easily recognized. 

Examples of such naming conventions are firstname.lastname.countrycode@domain.gov for a 

foreign national’s address, and firstname.lastname.ctr@domain.gov for a contractor’s address. 

8.1.4 Securing the Client Host’s Operating System 

Many host operating systems provide a number of configuration settings and other measures for 

increasing the security of the email client either directly or indirectly. The host operating system 

is a key component of the overall security of a client host. The following should be done to 

secure the host operating system: 

 Keep it updated to the most secure patch level. 

 Configure it to allow only the appropriate user(s) to access locally stored messages and mail 

client configuration files. 

 Configure (Windows hosts only) the Windows Script Host (WSH) [NSA01]: 

 

43 For more information on TLS and SSL, see NIST SP 800-52, Guidelines for the Selection and Use of Transport 

Layer Security (TLS) Implementations (http://csrc.nist.gov/publications/nistpubs/). 

73 
Guidelines on Electronic Mail Security (Draft) 

 Remove WSH or allow only administrator to access 

 Change the default action of the following files extensions from execute to edit:44

 JS (JavaScript) 

 JSE (JavaScript Encoded File) 

 VBE (VBScript Encoded File) 

 VBS (Visual Basic Script) 

 WS (Windows Script File) 

 WSC (Windows Script Component) 

 WSF (Windows Script File) 

 WSH (Windows Script Host Settings File) 

 On Windows hosts, ensure that they are configured to display the full file extensions (this will 

ensure that an email attachment such as iloveyou.txt.vbs is displayed instead of iloveyou.txt). 

 Install an anti-virus application and configure it to automatically scan all incoming messages 

and any attachments as they are opened.45 Also, install and use an anti-spyware application if 

the anti-virus software does not offer robust anti-spyware capabilities. 

 Install a personal firewall to protect the computer from unauthorized communications, unless 

the computer is already sufficiently protected by existing network security devices (e.g., 

network firewalls). 

 Ensure that the operating system enforces the concept of least privilege, because malicious 

code runs in the security context on which it was launched (i.e., the user’s access level). For 

example, users should only read and compose email using accounts without administratorlevel privileges. 

 Ensure that critical components of the operating system are protected from malicious code.46 

 Use a file encrypting application to protect the mail stored locally on the user’s hard drive (this 

is especially important for laptop computers and other mobile devices, which are more likely 

to be stolen). 

 

44 Some email clients may execute files with these extensions, even though the operating system is configured not to 

execute them. 

45 More information on anti-virus software is available from NIST SP 800-83, Guide to Malware Incident Prevention 

and Handling (http://csrc.nist.gov/publications/nistpubs/). 

46For more information, see NIST SP 800-28, Guidelines on Active Content and Mobile Code, and NIST SP 800-83, 

Guide to Malware Incident Prevention and Handling (http://csrc.nist.gov/publications/nistpubs/). 

74 
Guidelines on Electronic Mail Security (Draft) 

 Configure the operating system to automatically lock the current OS session after a fixed 

period of inactivity. 

8.2 Secure Message Composition 

Encryption should be used to securely send email messages containing sensitive information. 

Two primary methods for encrypting email are S/MIME and OpenPGP, which were discussed in 

Section 3. Both offer similar levels of protection, but their inherent architectures are different. 

Most mail clients support S/MIME natively, whereas OpenPGP usually comes in the form of a 

plug-in. Ultimately, the choice comes down to which solution meets the requirements of the 

organization. As a general rule, unencrypted email should be treated as a postcard – anyone can 

read and modify. 

Securing messages using S/MIME or OpenPGP involves obtaining digital certificates for both the 

sender and recipient. A digital certificate has several components, including the name and email 

address of the person to whom the certificate was issued, a public key and its expiration date, 

information about the CA that issued the certificate (including its digital signature), and the serial 

number of the certificate. When the sender has both the sender and receiver’s digital certificates, 

the sender can digitally sign and encrypt email messages to the recipient. Digitally signing a 

message is important in three ways: 

 Authenticity allows the recipient to be confident that the message is from the sender. 

 Non-repudiation ensures that the sender cannot deny creating the message. 

 Integrity ensures that the message has not accidentally or maliciously been altered during 

transmission from sender to recipient. 

Digital certificates can be obtained from either an internal certificate authority (CA) or a public, 

third-party CA.47 Table 3.3 contains a list of third-party CAs. 

For a mail client that is configured to send and receive encrypted messages, all received messages 

should be stored in their encrypted format. The mail client may also be configured to send and 

receive unencrypted, but authenticated, messages, where integrity is the primary concern. 

Depending on the sensitivity of the message, the mail client should be set to require a password 

each time the message is opened for reading. 

 

47 For more information about CAs, see NIST SP 800-32, Introduction to Public Key Technology and the Federal PKI 

Infrastructure (http://csrc.nist.gov/publications/nistpubs/). 

75 
Guidelines on Electronic Mail Security (Draft) 

8.3 Plug-ins 

A number of different plug-ins are available for mail clients. These plug-ins offer additional 

functionality beyond that of the basic mail client configuration. Mail encryption, anti-virus, popup blocker, and malware prevention plug-ins are a small subset of the types of plug-ins available. 

Some provide advanced filtering capabilities, whereas others provide audible notification of new 

messages. Regardless of the type of plug-in, care needs to be taken when installing them. 

Generally, only install plug-ins from trusted sources. Be wary of any plug-in that has not been 

distributed from the manufacturer in a digitally signed archive. Some plug-ins offering additional 

functionality may contain spyware that can track the Web sites a user visits or adware that 

delivers pop-up advertisements. They can come in the form of a toolbar that is automatically 

installed in your Internet browser. Using manufacturers’ Web sites to acquire plug-ins reduces 

the likelihood of installing a malicious plug-in. 

8.4 Accessing Web-Based Email Systems 

From a user standpoint, accessing a mail server via a Web browser can be efficient and 

convenient. Unfortunately, a number of security concerns should be carefully considered before 

implementing Web-based access to mail servers. Many of the concerns are the same as those for 

standard mail clients. For example, the default configuration for Web-based access normally 

sends passwords and data in the clear, such as those for POP and IMAP. For greater security, 

organizations should configure the mail server to accept Web connections only via 128-bit 

SSL/TLS connections.48 This setting causes both user authentication and email content to be 

encrypted during transmission from the user’s Web browser to the Web server. However, it does 

not protect the content as it is transmitted from the mail server to the recipient(s); some form of 

email encryption, such as S/MIME or OpenPGP, would need to be used if message 

confidentiality is required. Unfortunately, most Web-based email systems do not directly support 

them. One solution is to encrypt the data separately and then paste it into the browser for 

transmission (this is easily done with OpenPGP). 

Enabling Web-based access often requires a weakening in the overall security posture of the mail 

server. Organizations must be aware of the risks and carefully consider whether to implement 

Web-based access to their mail server (see Section 6.6). 

A serious risk with Web-based email systems is access from public computers (e.g., college 

computing lab, Internet café, public library). In these situations, the browser may be configured 

to store and recall usernames and passwords automatically. If it is configured this way, an 

unauthorized person may use these credentials to obtain access to the organization’s mail server. 

Another danger is that a public computer may have a keystroke logger that registers and saves all 

keystrokes entered by the mail user, including username and password. Again, this data could be 

used to access and compromise the organization’s mail server. Web browsers also temporarily 

cache a user’s credentials for a fixed period after the user logs in. If the user fails to empty the 

browser cache and close the browser after completing access to the mail server, it is possible for 

an unauthorized person to employ the cached credentials to access the organization’s mail server. 

The use of SSL/TLS does not generally protect against these dangers. 

 

48 For more information on SSL/TLS and its use with Web servers, see NIST SP 800-44, Guidelines on Securing 

Public Web Servers, and NIST SP 800-52, Guidelines for the Selection and Use of Transport Layer Security 

Implementations, (http://csrc.nist.gov/publications/nistpubs/index.html). 

76 
Guidelines on Electronic Mail Security (Draft) 

The security of Web-based email is based in large part on the expertise of users. For example, 

some Web-based mail clients ask users if they are using public or private computers; users should 

select the public option to further protect their email information. Thus, users should be carefully 

trained prior to being granted access to Web-based email. Organizations should also consider 

creating a “Rules of Behavior” agreement that each user signs, in which he or she acknowledges 

responsibility and accountability for the appropriate use of Web-based email. 

8.5 Mail Client (MUA) Security Checklist 

Completed Action

Patching and updating mail clients 

Update email client to newest or most secure version 

Apply any necessary patches to email client (in conformance with 

organizational polices and configuration management) 

Apply any necessary patches to Web browser (for email clients 

that are integrated with browser (e.g., Outlook) 

Configuring mail client security features 

Disable automatic message preview 

Disable automatic opening of messages 

Disable automatic loading of pictures in messages 

Disable downloading and processing of active content (if 

appropriate) 

Enable anti-spam and anti-phishing features 

Reconfigure portable email clients, such as those on cell phones 

and PDAs, to improve their security 

Ensure that security policy supports the protection of portable 

email clients, such as requiring anti-virus software to be installed 

and enabled 

Configuring authentication and access 

Enable secure authentication and access 

Disable ability of email client to store username and passwords 

Configure client to use encryption (TLS) for SMTP, POP, and 

IMAP communications 

Set restrictions on the selection of email addresses, such as 

ensuring they are unrelated to user account names 

Provide security for email message content (e.g., S/MIME, 

OpenPGP) 

Enable and install only absolutely necessary plug-ins from trusted 

sources 

Configure Web-based email access to only use 128-bit SSL/TLS 

connections 

Educate users on the vulnerabilities of Web-based email access 

77 
Guidelines on Electronic Mail Security (Draft) 

Completed Action

Securing the mail client host operating system 

Keep the OS updated to the most secure patch level 

Configure the OS to allow only the appropriate user(s) to access 

locally stored messages and mail client configuration files 

Secure or remove Windows Script Host (Windows hosts only) 

Change the default action on files associated with the Windows 

Script Host from execute to edit (Windows hosts only) 

Ensure that the OS is configured to show full file extensions 

(Windows hosts only) 

Install an anti-virus application and configure it to scan incoming 

messages and attachments; also install an anti-spyware application 

if the anti-virus software does not offer robust anti-spyware 

capabilities 

Install a personal firewall if needed to protect the computer from 

unauthorized communications 

Ensure the OS enforces the concept of least privilege, because 

malicious code runs in the security context on which it was 

launched (i.e., the user’s access level) 

Ensure that critical components of the operating system are 

protected from malicious code 

Use a file encrypting system to protect the mail stored locally on 

the user’s hard drive (especially important for laptop computers) 

Configure the OS to automatically lock the current session after a 

fixed period of inactivity 

78 
Guidelines on Electronic Mail Security (Draft) 

9. Securely Administering a Mail Server 

After initially deploying a mail server, administrators need to maintain its security continuously. 

This section provides general recommendations for securely administering mail servers. Vital 

activities include handling and analyzing log files; performing regular mail server backups; 

recovering from mail server compromises; testing the mail server’s security regularly; and 

performing remote administration securely. 

9.1 Logging 

Logging is a cornerstone of a sound security posture. Capturing the correct data in the logs and 

then monitoring those logs closely is vital.49 Network and system logs are important, especially 

system logs in the case of S/MIME or OpenPGP (see Section 3) enabled mail servers, where 

network monitoring is less effective. Mail server software can provide additional log data 

relevant to mail-specific events. 

Reviewing logs is mundane and reactive, and many mail server administrators devote their time 

to performing duties that they may consider more important or urgent. However, log files are 

often the only record of suspicious behavior. Enabling the mechanisms to log information allows 

the logs to be used to detect failed and successful intrusion attempts and to initiate alert 

notifications when further investigation is needed. Procedures and tools need to be in place to 

process and analyze the log files and to review alert notifications. 

Mail server logs provide: 

 Alerts to suspicious activities that require further investigation 

 Tracking of an attacker’s activities 

 Assistance in the recovery of the system 

 Assistance in post-event investigation 

 Required information for legal proceedings. 

The selection and implementation of specific mail server software determine which set of detailed 

instructions presented below the mail administrator should follow to establish logging 

configurations. Some of the guidance contained in the steps below may not be fully applicable to 

all manufacturers’ mail server software products. 

9.1.1 Recommended Generic Logging Configuration 

Although the logging capabilities of a mail server vary for each product, the following generic 

configuration is recommended. Set logging on the mail server to the standard level used within 

the organization. Once the overall logging detail level is set, ensure the following events are 

logged (if supported by the mail server software): 

 

49 For more information on logging, see NIST SP 800-92 (DRAFT), Guide to Computer Security Log Management, 

which is available at http://csrc.nist.gov/publications/nistpubs/. 

79 
Guidelines on Electronic Mail Security (Draft) 

 Local host related logging 

 IP stack setup errors 

 Resolver configuration problem (e.g., DNS, NIS) 

 Mail server configuration errors (e.g., mismatch with DNS: local configuration error, out 

of date alias database) 

 Lack of system resources (disk space, memory, CPU) 

 Alias database rebuilds 

 Connection-related logging 

 Failed logons, and also successful logons if adequate space is available 

 Security problems (e.g., spamming) 

 Lost communications (network problems) 

 Protocol failures 

 Connection timeouts 

 Connection rejections 

 Use of VRFY and EXPN commands 

 Message-related logging 

 Send on behalf of 

 Send as 

 Malformed addresses 

 Message collection statistics 

 Creation of error messages 

 Delivery failures (permanent errors) 

 Messages being deferred (transient errors). 

Ensuring that sufficient log capacity is available is a concern, since logs often take considerably 

more space than administrators initially estimate, especially when logging is set to a highly 

detailed level. Administrators should closely monitor the size of the log files when they 

80 
Guidelines on Electronic Mail Security (Draft) 

implement different logging settings to ensure that the log files do not fill up the allocated 

storage. Due to the size of the log files, removing and archiving the logs more frequently or 

reducing the logging level of detail may be necessary. 

Some mail server programs provide a capability to enforce or disable the checking of specified 

access controls during program startup. This level of control may be helpful, for example, to 

avoid inadvertent alteration of log files because of errors in file access administration. Mail 

server administrators should determine the circumstances under which they may wish to enable 

such checks (assuming the mail server software supports this feature). 

9.1.2 Reviewing and Retaining Log Files 

Reviewing log files is a tedious and time-consuming task which informs administrators of events 

that have already occurred. Accordingly, they are often useful for corroborating other evidence, 

such as a CPU utilization spike or anomalous network traffic reported by an IPS. When a log is 

used to corroborate other evidence, a focused review is in order. For example, if an IPS reported 

an inbound connection to the mail server at 8:17 a.m. that attempted to use the VRFY command, 

then a review of the logs generated just before 8:17 a.m. is appropriate. Mail server logs should 

also be reviewed for indications of attacks or spamming. The frequency of the reviews depends 

on the following factors: 

 Amount of traffic the server receives 

 General threat level (certain sites receive many more attacks than other sites and thus should 

review their logs more frequently) 

 Specific threats (at certain times specific threats arise that may require more frequent log file 

analysis) 

 Vulnerability of the mail server 

 Value of data and services provided by the mail server. 

Reviews should take place regularly (e.g., daily) and when a suspicious activity has been noted or 

a threat warning has been issued. Obviously, the task could quickly become burdensome to a 

mail administrator. To reduce this burden, automated log analysis tools have been developed (see 

Section 9.1.3). 

In addition, a long-term and more in-depth analysis of the logs is needed. Because a typical mail 

server attack can involve hundreds of unique requests, an attacker may attempt to disguise a mail 

attack by increasing the interval between requests. In this case, reviewing a single day’s or 

week’s logs may not show recognizable trends. However, when trends are analyzed over a week, 

month, or quarter, multiple attacks from the same host or subnet can be more easily recognized. 

Log files should be protected to ensure that if an attacker does compromise a mail server, the log 

files cannot be altered to cover the attack. Although encryption can be useful in protecting log 

files, the best solution is to store log files on a host separate from the mail server. This is often 

called a centralized logging server. Centralized logging is often performed using syslog, which is 

81 
Guidelines on Electronic Mail Security (Draft) 

a standard logging protocol.50 Alternately, some organizations use security information and 

event management (SIEM) software that uses centralized servers to perform log analysis, 

database servers to store logs, and agents installed on each host to parse particular types of logs, 

such as mail server logs, and transfer their data to the centralized servers.51 

Log files should be backed up and archived regularly. Archiving log files for a period of time is 

important for several reasons, including supporting certain legal actions and troubleshooting 

problems with the mail server. The retention period for archived log files depends on a number 

of factors, including: 

 Legal requirements 

 Organizational requirements 

 Size of logs (which is directly related to the traffic of the site and the number of details logged) 

 Value of mail server data and services 

 Threat level. 

9.1.3 Automated Log File Analysis Tools 

Most mail servers receive significant amounts of traffic, and the log files quickly become 

voluminous. Automated log analysis tools should be installed to ease the burden on the mail 

server administrator. These tools analyze the entries in the mail server log files and identify 

suspicious and unusual activity. As mentioned in Section 9.1.2, some organizations use SIEM 

software for centralized logging, which can also perform automated log file analysis. 

Many commercial and public domain tools are available to support regular analysis. The 

automated log analyzer should forward any suspicious events to the responsible mail 

administrator or security incident response team as soon as possible for follow-up investigation. 

Some organizations may wish to use two or more log analyzers, which will reduce the risk of 

missing an attack or other significant events in the log files. [NIST06b] 

9.2 Mail Server Backup Procedures 

One of the most important functions of a mail server administrator is to maintain the integrity of 

the data on the mail server. This is important because mail servers are often one of the most 

exposed and vital servers on an organization’s network. The mail administrator needs to perform 

backups of the mail server on a regular basis for several reasons. A mail server fails as a result of 

a malicious or unintentional act or a hardware or software failure. In addition, Federal agencies 

and many other organizations are governed by regulations on the backup and archiving of mail 

server data. Mail server data should also be backed up on a regular basis for legal and financial 

reasons. 

 

50 Syslog is defined in IETF RFC 3164, The BSD Syslog Protocol, which is available at 

http://www.ietf.org/rfc/rfc3164.txt. 

51 More information on syslog and SIEM implementations is provided in NIST SP 800-92 (DRAFT), Guide to 

Computer Security Log Management, which is available at http://csrc.nist.gov/publications/nistpubs/

82 
Guidelines on Electronic Mail Security (Draft) 

All organizations need to create a mail server data backup policy. The contents of this policy will 

be influenced by three factors: 

 Legal requirements 

 Applicable laws and regulations (Federal, state, and international) 

 Litigation requirements 

 Mission requirements 

 Contractual 

 Common practices 

 Criticality of data to organization 

 Organizational guidelines and policies. 

Although each organization’s mail server backup policy will be different to reflect its particular 

environment, it should address the following issues: 

 The purpose of the mail server backup policy 

 The parties affected by the mail server backup policy 

 The mail servers covered by the backup policy 

 The definitions of key terms, especially legal and technical 

 The detailed requirements from the legal, business, and organization’s perspective 

 The required frequency of backups 

 The procedures for ensuring data is properly retained and protected 

 The procedures for ensuring data is properly destroyed or archived when no longer required 

 The procedures for preserving information for Freedom of Information Act (FOIA) requests, 

legal investigations, and other such requests 

 The responsibilities of those involved in data retention, protection, and destruction activities 

 The retention period for each type of information logged52

 

52 Organizations should carefully consider the retention period for email messages, transaction logs, and other mail 

server-related records. Many organizations are subject to multiple sets of legal and regulatory requirements that can 

affect their retention of email records. The National Archives and Records Administration (NARA) has a Web site for 

Federal records management, which is located at http://www.archives.gov/records-mgmt/. Additional information on 

NARA regulations related to mail retention is available at http://edocket.access.gpo.gov/2006/pdf/06-1545.pdf. Federal 

83 
Guidelines on Electronic Mail Security (Draft) 

 The specific duties of the central/organizational data backup team, if one exists. 

Three primary types of backups exist: full, incremental, and differential. Full backups include the 

operating system, applications, and data stored on the mail server (i.e., an image of every piece of 

data stored on the mail server hard drives). The advantage of a full backup is that it is easy to 

restore the entire mail server back to the state (e.g., configuration, patch level, data) it was in 

when the backup was performed. The disadvantage of full backups is that they take considerable 

time and resources to perform. Incremental backups reduce the impact by backing up only data 

that has changed since the previous backup (either full or incremental). 

Differential backups reduce the number of backup sets that must be accessed to restore a 

configuration by backing up all changed data since the last full backup. However, each 

differential backup will become increasingly larger as time lapses from the last full backup, 

taking more processing time and storage than an incremental backup would. Generally, full 

backups are performed less frequently (weekly to monthly or when a significant change occurs), 

and incremental or differential backups are performed more frequently (daily to weekly). The 

frequency of backups will be determined by several factors: 

 Volatility of information on and configuring of the mail server 

 Amount of data to be backed up 

 Backup device and media available 

 Time available for dumping backup data 

 Criticality of data 

 Threat level faced by mail server 

 Effort required to data reconstruction without data backup 

 Other data backup or redundancy features of mail server (e.g., Redundant Array of 

Inexpensive Disks [RAID]. 

When archiving or backing up mail data, organizations should generally conform to the following 

guidelines: 

 Employ write-once, read-many media (to prevent the alteration or accidental erasure of 

archived information) 

 Contain a verification capability to ensure that data is being correctly backed up or archived 

 Include the capability to serialize and time-date the information stored 

 Provide for easy retrieval of indexes and records preserved on the backup media 

 

agencies often retain email messages for an extended period of time, such as a year or more, whereas other 

organizations more commonly retain messages for only 30 to 90 days. 

84 
Guidelines on Electronic Mail Security (Draft) 

 Maintain at least two copies in two geographically distinct locations 

 Accurately organize and index all information maintained on both original and duplicate 

storage media. 

9.3 Recovering from a Security Compromise 

Most organizations eventually face a successful compromise of one or more hosts on their 

network. The first step in recovering from a compromise is to create and document the required 

policies and procedures for responding to successful intrusions before an intrusion.53 The 

response procedures should outline the actions that are required to respond to a successful 

compromise of the mail server and the appropriate sequence of these actions (sequence can be 

critically important). Most organizations already have a dedicated incident response team in 

place which should be contacted immediately when there is suspicion or confirmation of a 

compromise. In addition, the organization may wish to ensure that some of its staff are 

knowledgeable in the fields of computer and network forensics.54 

A mail server administrator should follow the organization’s policies and procedures for incident 

handling, and the incident response team should be contacted for guidance before taking any 

action after a suspected or confirmed security compromise. Examples of steps commonly 

performed after discovering a successful compromise are as follows: 

 Report the incident to the organization’s computer incident response capability 

 Isolate the compromised systems or take other steps to contain the attack so that additional 

information can be collected55

 Consult, as appropriate, with management, legal counsel, and law enforcement expeditiously 

 Investigate similar56 hosts to determine if the attacker also has compromised other systems 

 Analyze the intrusion, including: 

 Capture the current state of the server starting with the most ephemeral data first (e.g., 

current network connections, memory dump, files time stamps, logged in users, etc.) 

 Modifications made to the system’s software and configuration 

 

53 For more information on this area, see NIST SP 800-61, Computer Security Incident Handling Guide, and NIST SP 

800-18 Revision 1, Guide for Developing Security Plans for Federal Information Systems

(http://csrc.nist.gov/publications/nistpubs/index.html). 

54 More information on computer and network forensics is available from NIST SP 800-86, Guide to Integrating 

Forensic Techniques into Incident Response (http://csrc.nist.gov/publications/nistpubs/index.html). 

55 Isolating the system must be accomplished with great care if the organization wishes to collect evidence. Many 

attackers configure compromised systems to erase evidence if a compromised system is disconnected from the network 

or rebooted. One method to isolate a system would be to reconfigure the nearest upstream switch or router. 

56 Similar hosts would include hosts that are in the same IP address range, have the same or similar passwords, share a 

trust relationship, and/or have the same operating system and/or applications. 

85 
Guidelines on Electronic Mail Security (Draft) 

 Modifications made to the data 

 Tools or data left behind by attacker 

 System logs, intrusion detection, and firewall log files 

 Restore the system 

 One of the following two options: 

 Install clean version of operating system 

 Restore from backups (this option can be more risky, as the backups may have been 

made after the compromise, and restoring from a compromised backup may still allow 

the attacker access to the system) 

 Disable unnecessary services 

 Apply all patches 

 Change all passwords (even on uncompromised hosts as required) 

 Reconfigure network security elements (firewall, router, IPS) to provide additional 

protection and notification 

 Test system to ensure security 

 Reconnect system to network 

 Monitor system and network for signs that the attacker is attempting to access the system or 

network again 

 Document lessons learned. 

System administrators should decide whether to reinstall the operating system of a compromised 

system or restore it from a backup based on organization policy and procedures. Factors that are 

often considered include the following: 

 Level of access that the attacker gained (e.g., root, user, guest, system) 

 Type of attacker (internal or external) 

 Purpose of the compromise (e.g., mail spoofing, illegal software repository, platform for other 

attacks) 

 Method used for the system compromise 

 Actions of the attacker during and after the compromise (e.g., log files, intrusion detection 

reports) 

86 
Guidelines on Electronic Mail Security (Draft) 

 Duration of the compromise 

 Extent of the compromise on the network (e.g., the number of hosts compromised) 

 Results of consultation with management and legal counsel. 

The lower the level of access gained by the attacker and the more the mail server administrator 

understands about the attacker’s actions, the less risk there is in restoring from a backup and 

patching the vulnerability. For incidents in which there is less known about the attacker’s actions 

and/or in which the attacker gains high-level access, it is recommended that the operating system 

and applications be reinstalled from the manufacturer’s original distribution media and that the 

mail server data be restored from a known good backup. 

If legal action is pursued, system administrators need to be aware of the guidelines for handling a 

host after a compromise. Consult legal counsel and relevant law enforcement authorities as 

appropriate. 

9.4 Security Testing Mail Servers 

Periodic security testing of public mail servers is critical.57 Without periodic testing, there is no 

assurance that current protective measures are working or that the security patch just applied by 

the mail server administrator is functioning as advertised. Although a variety of security testing 

techniques exists, vulnerability scanning is the most common. Vulnerability scanning assists a 

mail server administrator in identifying vulnerabilities and verifying whether the existing security 

measures are effective. Penetration testing is also used, but less frequently and usually only as 

part of an overall penetration test of the organization’s network.58 

9.4.1 Vulnerability Scanning 

Vulnerability scanners are automated tools that are used to identify vulnerabilities and 

misconfiguration of hosts. Many vulnerability scanners also provide information about 

mitigating discovered vulnerabilities. 

Vulnerability scanners attempt to identify vulnerabilities in the hosts scanned. Vulnerability 

scanners can help identify out-of-date software versions, missing patches or system upgrades, and 

validate compliance with or deviations from the organization's security policy. To accomplish 

this effort, vulnerability scanners identify operating systems and major software applications 

running on hosts and match them with known vulnerabilities. Vulnerability scanners employ 

large databases of vulnerabilities to identify vulnerabilities associated with commonly used 

operating systems and applications. 

However, vulnerability scanners have some significant weaknesses. Generally, they identify only 

surface vulnerabilities and are unable to address the overall risk level of a scanned mail server. 

 

57 If Web-based mail access is being provided, periodic security testing of the Web servers providing that access is also 

critical. See NIST SP 800-44, Guidelines on Securing Public Web Servers, for information on performing security 

testing for Web servers. It is available at http://csrc.nist.gov/publications/nistpubs/. 

58 For information about other testing techniques, see NIST SP 800-42, Guideline on Network Security Testing 

(http://csrc.nist.gov/publications/nistpubs/index.html). 

87 
Guidelines on Electronic Mail Security (Draft) 

Although the scan process itself is highly automated, vulnerability scanners can have a high false 

positive error rate (reporting vulnerabilities when none exist). This means an individual with 

expertise in mail server security and administration must interpret the results. Furthermore, 

vulnerability scanners cannot generally identify vulnerabilities in custom code or applications. 

Vulnerability scanners rely on periodic updating of the vulnerability database to recognize the 

latest vulnerabilities. Before running any scanner, mail server administrators should install the 

latest updates to its vulnerability database. Some vulnerability scanner databases are updated 

more regularly than others (the frequency of updates should be a major consideration when 

choosing a vulnerability scanner). 

Vulnerability scanners are often better at detecting well-known vulnerabilities rather than more 

esoteric ones because it is impossible for any one scanning product to incorporate all known 

vulnerabilities in a timely manner. In addition, manufacturers want to keep the speed of their 

scanners high (more vulnerabilities detected requires more tests, which slows the overall scanning 

process). Therefore, vulnerability scanners may be of little use to mail server administrators 

operating less popular mail servers, operating systems, or custom-coded applications. 

Vulnerability scanners provide the following capabilities: 

 Identifying active hosts on network 

 Identifying active services (ports) on hosts and which of these are vulnerable 

 Identifying applications and banner grabbing 

 Identifying operating systems 

 Identifying vulnerabilities associated with discovered operating systems and applications 

 Testing compliance with host application usage/security policies. 

Organizations should conduct vulnerability scanning to validate that operating systems and mail 

server applications are up to date on security patches and software versions. Vulnerability 

scanning is a labor-intensive activity that requires a high degree of human involvement to 

interpret the results. It may also be disruptive to operations by taking up network bandwidth, 

slowing network response times and potentially impacting the availability of the scanned server 

or its applications. However, vulnerability scanning is extremely important for ensuring that 

vulnerabilities are mitigated as soon as possible, before they are discovered and exploited by 

adversaries. Vulnerability scanning should be conducted on a weekly to monthly basis. Many 

organizations also run a vulnerability scan whenever a new vulnerability database is released for 

the organization’s scanner application. Vulnerability scanning results should be documented and 

discovered deficiencies corrected. 

Organizations should also consider running more than one vulnerability scanner. As previously 

discussed, no scanner is able to detect all known vulnerabilities; however, using two scanners will 

generally increase the number of vulnerabilities detected. A common practice is to use one 

commercial and one freeware scanner. Network- and host-based vulnerability scanners are 

available for free or for a fee. 

88 
Guidelines on Electronic Mail Security (Draft) 

9.4.2 Penetration Testing 

“Penetration testing is security testing in which evaluators attempt to circumvent the security 

features of a system based on their understanding of the system design and implementation” 

[NISS99]. The purpose of penetration testing is to exercise system protections (particularly 

human response to attack indications) by using common tools and techniques developed by 

attackers. This testing is highly recommended for complex or critical systems. 

Penetration testing can be an invaluable technique for any organization’s information security 

program. However, it is a very labor-intensive activity and requires great expertise to minimize 

the risk to targeted systems. At a minimum, it may slow the organization’s network response 

time because of network mapping and vulnerability scanning. Furthermore, the possibility exists 

that systems may be damaged or rendered inoperable in the course of penetration testing. 

Although this risk is mitigated by the use of experienced penetration testers, it can never be fully 

eliminated. 

Penetration testing does offer the following benefits [NIST02b]: 

 Tests the network using the same methodologies and tools employed by attackers 

 Verifies whether vulnerabilities exist 

 Goes beyond surface vulnerabilities and demonstrates how these vulnerabilities can be 

exploited iteratively to gain greater access 

 Demonstrates that vulnerabilities are not purely theoretical 

 Provides the “realism” necessary to address security issues 

 Allows for testing of procedures and the susceptibility of the human element to social 

engineering. 

9.5 Remotely Administering a Mail Server 

It is strongly recommended that remote administration of a mail server be allowed only after 

careful consideration of the risks.59 The most secure configuration is to disallow any remote 

administration. However, that may not be viable for all organizations. The risk of enabling 

remote administration varies considerably depending on the location of the mail server on the 

network (see Section 7.1). For a mail server that is located behind a firewall, remote 

administration or content updating can be implemented relatively securely from the internal 

network, but not without added risk. Remote administration should generally not be allowed 

from a host located outside the organization’s network unless performed from an organizationcontrolled computer through the organization’s remote access solution, such as a virtual private 

network. 

 

59 Similar caution is needed for Web servers used for Web-based mail access. See NIST SP 800-44, Guidelines on 

Securing Public Web Servers, for additional information (http://csrc.nist.gov/publications/nistpubs/). 

89 
Guidelines on Electronic Mail Security (Draft) 

If an organization determines that it is necessary to remotely administer or update content on a 

mail server, following these steps should ensure that it is implemented in as secure a manner as 

possible: 

 Use a strong authentication mechanism (e.g., public/private key pair, two factor 

authentication). 

 Restrict which hosts can be used to remotely administer or update content on the mail server: 

 Restrict by authorized users 

 Restrict by IP address (not hostname) 

 Restrict to hosts on the internal network or those using the organization’s enterprise 

remote access solution 

 Use secure protocols that can provide encryption for both passwords and data, such as secure 

shell [SSH] or Secure HTTP [HTTPS], and not less secure protocols (e.g., Telnet, FTP, NFS, 

HTTP) unless absolutely required and tunneled over an encrypted protocol such SSH, SSL or 

IPsec. 

 Enforce the concept of least privilege on remote administration and content updating (e.g., 

attempt to minimize the access rights for the remote administration/update accounts). 

 Do not allow remote administration from the Internet through the firewall unless accomplished 

via strong mechanisms such as VPNs. 

 Change any default accounts or passwords from the remote administration utility or 

application. 

 Do not mount any file shares on the internal network from the mail server or vice versa. 

9.6 Securely Administering a Mail Server Checklist 

Completed Action

Logging 

Log IP stack setup errors 

Log resolver configuration problem (e.g., DNS, NIS) 

Log mail server configuration errors (e.g., mismatch with DNS, 

local configuration error, out-of-date alias database) 

Log out of date alias databases 

Log lack of system resources (e.g., disk space, memory, CPU) 

Log alias database rebuilds 

Log logons (successful and failed) 

Log security problems (e.g., spamming) 

Log lost communications (network problems) 

90 
Guidelines on Electronic Mail Security (Draft) 

Completed Action

Log protocol failures 

Log connection timeouts 

Log connection rejections 

Log use of VRFY and EXPN commands 

Log send on behalf of 

Log send as 

Log malformed addresses 

Log message collection statistics 

Log creation of error messages 

Log delivery failures (permanent errors) 

Log messages being deferred (transient errors) 

Store logs on a separate logging server 

Archive logs according to organizational requirements 

Review logs daily 

Review logs weekly (for more long-term trends) 

Use automated log file analysis tool(s) 

Mail server backups 

Create a mail server backup policy 

Back up mail server differentially or incrementally on a daily to 

weekly basis 

Back up mail server fully on a weekly to monthly basis 

Periodically archive backups 

Recovering from a compromise 

Report incident to organization’s computer incident response 

capability 

Isolate compromised system(s) or take other steps to contain 

attack so additional evidence can be collected 

Consult, as appropriate, with management, legal counsel, and law 

enforcement officials expeditiously 

Investigate similar hosts to determine if the attacker has also 

compromised other systems 

Analyze the intrusion 

Restore the system 

Test system to ensure security 

Reconnect system to network 

Monitor system and network for signs that the attacker is 

attempting to access the system or network again 

91 
Guidelines on Electronic Mail Security (Draft) 

Completed Action

Document lessons learned 

Security testing 

Periodically conduct vulnerability scans on mail server and 

supporting network 

Update vulnerability scanner before testing 

Correct any deficiencies identified by the vulnerability scanner 

Conduct penetration testing on the mail server and the supporting 

network infrastructure 

Correct deficiencies identified by penetration testing 

Remote administration 

Use a strong authentication mechanism (e.g., public/private key 

pair, two factor authentication) 

Restrict hosts that can be used to remotely administer on the mail 

server by IP address and to the internal network 

Use secure protocols (e.g., SSH, HTTPS) 

Enforce the concept of least privilege on remote administration 

(e.g., attempt to minimize the access rights for the remote 

administration/update accounts) 

Change any default accounts or passwords for the remote 

administration utility or application 

Do not allow remote administration from the Internet unless 

mechanisms such as VPN are used 

92 
Guidelines on Electronic Mail Security (Draft) 

Appendix A. Glossary 

Address Resolution Protocol (ARP) – A protocol used to obtain a node’s physical address. A 

client station broadcasts an ARP request onto the network with the Internet Protocol (IP) address 

of the target node it wishes to communicate with, and the node with that address responds by 

sending back its physical address so that packets can be transmitted to it. 

Body – The section of a mail message that contains the actual content of the message. 

Demilitarized Zone (DMZ) – A host or network segment inserted as a “neutral zone” between 

an organization’s private network and the Internet. 

Header – The section of a mail message that contains the vital information about the message, 

including origination date, sender, recipient(s), delivery path, subject, and format information. 

The header is generally left in clear text even when the body of the mail message is encrypted. 

Host – Almost any kind of computer, from a centralized mainframe that is a host to its terminals, 

to a server that is host to its clients, to a desktop personal computer (PC) that is host to its 

peripherals. In network architectures, a client station (user’s machine) is also considered a host 

because it is a source of information to the network, in contrast to a device such as a router or 

switch that directs traffic. 

Hotfix – Microsoft’s term for “patch”.

Internet Message Access Protocol (IMAP) – A mailbox access protocol defined by IETF RFC 

3501. IMAP is one of the most commonly used mailbox access protocols. IMAP offers a much 

wider command set than POP.

Local Delivery Agent (LDA) – A program running on a mail server that delivers messages 

between a sender and recipient if their mailboxes are both on the same mail server. An LDA may 

also process the message based on a predefined message filter before delivery. 

Mail Server – A host that provides “electronic post office” facilities. It stores incoming mail for 

distribution to users and forwards outgoing mail. The term may refer to just the application that 

performs this service, which can reside on a machine with other services, but for this document 

the term refers to the entire host including the mail server application, the host operating system 

and the supporting hardware. 

Mail Server Administrator – The mail server equivalent of a system administrator. Mail server 

administrators are system architects responsible for the overall design and implementation of mail 

servers. 

Mail Transfer Agent (MTA) – A program running on a mail server that receives messages from 

mail user agents or other MTAs and either forwards them to another MTA or, if the recipient is 

on the MTA, delivers the message to the local delivery agent (LDA) for delivery to the recipient. 

Common MTAs include Microsoft Exchange and sendmail.

Mail User Agent (MUA) – A mail client application used by an end user to access a mail server 

to read, compose, and send email messages. Common MUAs include Microsoft Outlook and 

Mozilla Thunderbird. 

A-1 
Guidelines on Electronic Mail Security (Draft) 

Malware – A program that is inserted into a system, usually covertly, with the intent of 

compromising the confidentiality, integrity, or availability of the victim’s data, applications, or 

operating system or of otherwise annoying or disrupting the victim. 

Multipurpose Internet Mail Extensions (MIME) – A protocol that makes use of the headers in 

an IETF RFC 2822 message to describe the structure of rich message content. 

Network Administrator – A person who manages a local area network (LAN) within an 

organization. Responsibilities include network security, installing new applications, distributing 

software upgrades, monitoring daily activity, enforcing licensing agreements, developing a 

storage management program, and providing for routine backups. 

Open Pretty Good Privacy (OpenPGP) – A protocol defined in IETF RFCs 2440 and 3156 for 

encrypting messages and creating certificates using public key cryptography. Most mail clients 

do not support OpenPGP by default; instead, third-party plug-ins can be used in conjunction with 

the mail clients. OpenPGP uses a “web of trust” model for key management, which relies on 

users for management and control, making it unsuitable for medium to large implementations.

Operating System – The software “master control application” that runs the computer. It is the 

first program loaded when the computer is turned on, and its principal component, the kernel, 

resides in memory at all times. The operating system sets the standards for all application 

programs (such as the mail server) that run in the computer. The applications communicate with 

the operating system for most user interface and file management operations. 

Patch – A “repair job” for a piece of programming; also known as a “fix”. A patch is the 

immediate solution that is provided to users; it can sometimes be downloaded from the software 

maker's Web site. The patch is not necessarily the best solution for the problem, and the product 

developers often find a better solution to provide when they package the product for its next 

release. A patch is usually developed and distributed as a replacement for or an insertion in 

compiled code (that is, in a binary file or object module). In many operating systems, a special 

program is provided to manage and track the installation of patches. 

Phishing – Tricking individuals into disclosing sensitive personal information through deceptive 

computer-based means. 

Post Office Protocol (POP) – A mailbox access protocol defined by IETF RFC 1939. POP is 

one of the most commonly used mailbox access protocols.

Service Pack – A collection of patches integrated into a single large update.

Secure Multipurpose Internet Mail Extensions (S/MIME) – A protocol defined in IETF RFCs 

3850 through 3852 and 2634 for encrypting messages and creating certificates using public key 

cryptography. S/MIME is supported by default installations of many popular email clients. 

S/MIME uses a classic, hierarchical design based on certificate authorities for its key 

management, making it suitable for medium to large implementations.

Simple Mail Transfer Protocol (SMTP) – An MTA protocol defined by IETF RFC 2821. 

SMTP is the most commonly used MTA protocol. 

Spam – Unsolicited bulk commercial email messages.

A-2 
Guidelines on Electronic Mail Security (Draft) 

Spyware – Malware intended to violate a user’s privacy. 

System – See “host”. 

System Administrator – A person who manages a computer system, including its operating 

system and applications. Responsibilities are similar to that of a network administrator. 

Vulnerability – A security exposure in an operating system or other system software or 

application software component. A variety of organizations maintain publicly accessible 

databases of vulnerabilities based on the version numbers of software. Each vulnerability can 

potentially compromise the system or network if exploited. 

Web Server – A computer that provides World Wide Web (WWW) services on the Internet. It 

includes the hardware, operating system, Web server software, and Web site content (Web 

pages). If the Web server is used internally and not by the public, it may be known as an “intranet 

server”. 

A-3 
Guidelines on Electronic Mail Security (Draft) 

B-1 

Appendix B. Mail-Related RFCs 

This appendix contains lists of IETF RFCs that are related to email and email security. The first 

list contains an extensive list of RFCs, sorted by RFC number. The subsequent lists contain 

subsets of the first list, focused on particular protocols such as IMAP4, POP, SMTP, and MIME. 

Mail-Related RFCs by RFC Number

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

1731 IMAP4 Authentication Mechanisms http://www.ietf.org/rfc/rfc1731.txt 

1732 IMAP4 Compatibility with IMAP2 and 

IMAP2BIS 

http://www.ietf.org/rfc/rfc1732.txt 

1733 Distributed Electronic Mail Models in 

IMAP4 

http://www.ietf.org/rfc/rfc1733.txt 

1870 SMTP Service Extension for Message Size 

Declaration 

http://www.ietf.org/rfc/rfc1870.txt RFC 1653 

1939 Post Office Protocol - Version 3 http://www.ietf.org/rfc/rfc1939.txt RFC 1725 

1957 Some Observations on Implementations of 

the Post Office Protocol (POP3) 

http://www.ietf.org/rfc/rfc1957.txt RFC 1939 

(updates) 

1985 SMTP Service Extension for Remote 

Message Queue Starting 

http://www.ietf.org/rfc/rfc1985.txt 

1991 PGP Message Exchange Formats http://www.ietf.org/rfc/rfc1991.txt 

2015 MIME Security with Pretty Good Privacy 

(PGP) 

http://www.ietf.org/rfc/rfc2015.txt 

2034 SMTP Service Extension for Returning 

Enhanced Error Codes 

http://www.ietf.org/rfc/rfc2034.txt 

2045 Multipurpose Internet Mail Extensions 

(MIME) Part One: Format of Internet 

Message Bodies 

http://www.ietf.org/rfc/rfc2045.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2046 Multipurpose Internet Mail Extensions 

(MIME) Part Two: Media Types 

http://www.ietf.org/rfc/rfc2046.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2047 MIME (Multipurpose Internet Mail 

Extensions) Part Three: Message Header 

Extensions for Non-ASCII Text 

http://www.ietf.org/rfc/rfc2047.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2049 Multipurpose Internet Mail Extensions 

(MIME) Part Five: Conformance Criteria 

and Examples 

http://www.ietf.org/rfc/rfc2049.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2061 IMAP4 Compatibility with IMAP2BIS http://www.ietf.org/rfc/rfc2061.txt 

2062 Internet Message Access Protocol – 

Obsolete Syntax 

http://www.ietf.org/rfc/rfc2062.txt 
Guidelines on Electronic Mail Security (Draft) 

B-2 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

2087 IMAP4 QUOTA extension http://www.ietf.org/rfc/rfc2087.txt 

2088 IMAP4 non-synchronizing literals http://www.ietf.org/rfc/rfc2088.txt 

2177 IMAP4 IDLE command http://www.ietf.org/rfc/rfc2177.txt 

2180 IMAP4 Multi-Accessed Mailbox Practice http://www.ietf.org/rfc/rfc2180.txt 

2192 IMAP URL Scheme http://www.ietf.org/rfc/rfc2192.txt 

2193 IMAP4 Mailbox Referrals http://www.ietf.org/rfc/rfc2193.txt 

2195 IMAP/POP AUTHorize Extension for 

Simple Challenge/Response 

http://www.ietf.org/rfc/rfc2195.txt RFC 2095 

2221 IMAP4 Login Referrals http://www.ietf.org/rfc/rfc2221.txt 

2268 A Description of the RC2 Encryption 

Algorithm 

http://www.ietf.org/rfc/rfc2268.txt 

2311 S/MIME Version 2 Message Specification http://www.ietf.org/rfc/rfc2311.txt 

2312 S/MIME Version 2 Certificate Handling http://www.ietf.org/rfc/rfc2312.txt 

2313 PKCS #1: RSA Encryption Version 1.5 http://www.ietf.org/rfc/rfc2313.txt 

2314 PKCS #10: Certification Request Syntax 

Version 1.5 

http://www.ietf.org/rfc/rfc2314.txt 

2315 PKCS #7: Cryptographic Message Syntax 

Version 1.5 

http://www.ietf.org/rfc/rfc2315.txt 

2342 IMAP4 Namespace http://www.ietf.org/rfc/rfc2342.txt 

2384 POP URL Scheme http://www.ietf.org/rfc/rfc2384.txt 

2440 OpenPGP Message Format http://www.ietf.org/rfc/rfc2440.txt 

2442 The Batch SMTP Media Type http://www.ietf.org/rfc/rfc2442.txt 

2449 POP3 Extension Mechanism http://www.ietf.org/rfc/rfc2449.txt RFC 1939 

(updates) 

2505 Anti-Spam Recommendations for SMTP 

MTAs 

http://www.ietf.org/rfc/rfc2505.txt 

2554 SMTP Service Extension for Authentication http://www.ietf.org/rfc/rfc2554.txt 

2595 Using TLS with IMAP, POP3 and ACAP http://www.ietf.org/rfc/rfc2595.txt 

2630 Cryptographic Message Syntax http://www.ietf.org/rfc/rfc2630.txt 

2632 S/MIME Version 3 Certificate Handling http://www.ietf.org/rfc/rfc2632.txt 

2633 S/MIME Version 3 Message Specification http://www.ietf.org/rfc/rfc2633.txt 

2634 Enhanced Security Services for S/MIME http://www.ietf.org/rfc/rfc2634.txt 

2645 On-Demand Mail Relay (ODMR) SMTP 

with Dynamic IP Addresses 

http://www.ietf.org/rfc/rfc2645.txt 

2683 IMAP4 Implementation Recommendations http://www.ietf.org/rfc/rfc2683.txt 
Guidelines on Electronic Mail Security (Draft) 

B-3 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

2821 Simple Mail Transfer Protocol http://www.ietf.org/rfc/rfc2821.txt RFC 821, 

RFC 974, 

RFC 1869, 

RFC 1123 

(updates) 

2822 Internet Message Format http://www.ietf.org/rfc/rfc2822.txt RFC 822 

2846 GSTN Address Element Extensions in Email Services http://www.ietf.org/rfc/rfc2846.txt 

2852 Deliver By SMTP Service Extension http://www.ietf.org/rfc/rfc2852.txt RFC 1894 

(updates) 

2920 SMTP Service Extension for Command 

Pipelining 

http://www.ietf.org/rfc/rfc2920.txt RFC 2197 

2971 IMAP4 ID extension http://www.ietf.org/rfc/rfc2971.txt 

3030 SMTP Service Extensions for Transmission 

of Large and Binary MIME Messages 

http://www.ietf.org/rfc/rfc3030.txt RFC 1830 

3156 MIME Security with OpenPGP http://www.ietf.org/rfc/rfc3156.txt RFC 2015 

(updates) 

3191 Minimal GSTN address format in Internet 

Mail 

http://www.ietf.org/rfc/rfc3191.txt RFC 2303, 

RFC 2846 

(updates) 

3192 Minimal FAX address format in Internet 

Mail 

http://www.ietf.org/rfc/rfc3192.txt RFC 2304, 

RFC 2846 

(updates) 

3206 The SYS and AUTH POP Response Codes http://www.ietf.org/rfc/rfc3206.txt 

3207 SMTP Service Extension for Secure SMTP 

over Transport Layer Security 

http://www.ietf.org/rfc/rfc3207.txt RFC 2487 

3348 The Internet Message Action Protocol 

(IMAP4) Child Mailbox Extension 

http://www.ietf.org/rfc/rfc3348.txt 

3461 Simple Mail Transfer Protocol (SMTP) 

Service Extension for Delivery Status 

Notifications (DSNs) 

http://www.ietf.org/rfc/rfc3461.txt RFC 1891 

3462 The Multipart/Report Content Type for the 

Reporting of Mail System Administrative 

Messages 

http://www.ietf.org/rfc/rfc3462.txt RFC 1892 

3463 Enhanced Mail System Status Codes http://www.ietf.org/rfc/rfc3463.txt RFC 1893 

3464 An Extensible Message Format for Delivery 

Status Notifications 

http://www.ietf.org/rfc/rfc3464.txt RFC 1894 

3501 Internet Message Access Protocol - Version 

4rev1 

http://www.ietf.org/rfc/rfc3501.txt RFC 2060 

3502 Internet Message Access Protocol (IMAP) – 

MULTIAPPEND Extension 

http://www.ietf.org/rfc/rfc3502.txt 
Guidelines on Electronic Mail Security (Draft) 

B-4 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

3503 Message Disposition Notification (MDN) 

profile for Internet Message Access Protocol 

(IMAP) 

http://www.ietf.org/rfc/rfc3503.txt 

3516 IMAP4 Binary Content Extension http://www.ietf.org/rfc/rfc3516.txt 

3691 Internet Message Access Protocol (IMAP) 

UNSELECT command 

http://www.ietf.org/rfc/rfc3691.txt 

3798 Message Disposition Notification http://www.ietf.org/rfc/rfc3798.txt RFC 2298, 

RFC 2046 

(updates), 

RFC 3461 

(updates) 

3848 ESMTP and LMTP Transmission Types 

Registration 

http://www.ietf.org/rfc/rfc3848.txt 

3865 A No Soliciting Simple Mail Transfer 

Protocol (SMTP) Service Extension 

http://www.ietf.org/rfc/rfc3865.txt 

3885 SMTP Service Extension for Message 

Tracking 

http://www.ietf.org/rfc/rfc3885.txt RFC 3461 

(updates) 

3886 An Extensible Message Format for Message 

Tracking Responses 

http://www.ietf.org/rfc/rfc3886.txt RFC 3463 

(updates) 

3974 SMTP Operational Experience in Mixed 

IPv4/v6 Environments 

http://www.ietf.org/rfc/rfc3974.txt 

4141 SMTP and MIME Extensions for Content 

Conversion 

http://www.ietf.org/rfc/rfc4141.txt 

4289 Multipurpose Internet Mail Extensions 

(MIME) Part Four: Registration Procedures 

http://www.ietf.org/rfc/rfc4289.txt RFC 2048 

4314 IMAP4 Access Control List (ACL) 

Extension 

http://www.ietf.org/rfc/rfc4314.txt RFC 2086 

4315 Internet Message Access Protocol (IMAP) - 

UIDPLUS extension 

http://www.ietf.org/rfc/rfc4315.txt RFC 2359 
Guidelines on Electronic Mail Security (Draft) 

B-5 

IMAP-Related RFCs by RFC Number 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

1731 IMAP4 Authentication Mechanisms http://www.ietf.org/rfc/rfc1731.txt 

1732 IMAP4 Compatibility with IMAP2 and 

IMAP2BIS 

http://www.ietf.org/rfc/rfc1732.txt 

1733 Distributed Electronic Mail Models in 

IMAP4 

http://www.ietf.org/rfc/rfc1733.txt 

2061 IMAP4 Compatibility with IMAP2BIS http://www.ietf.org/rfc/rfc2061.txt 

2062 Internet Message Access Protocol – 

Obsolete Syntax 

http://www.ietf.org/rfc/rfc2062.txt 

2087 IMAP4 QUOTA extension http://www.ietf.org/rfc/rfc2087.txt 

2088 IMAP4 non-synchronizing literals http://www.ietf.org/rfc/rfc2088.txt 

2177 IMAP4 IDLE command http://www.ietf.org/rfc/rfc2177.txt 

2180 IMAP4 Multi-Accessed Mailbox Practice http://www.ietf.org/rfc/rfc2180.txt 

2192 IMAP URL Scheme http://www.ietf.org/rfc/rfc2192.txt 

2193 IMAP4 Mailbox Referrals http://www.ietf.org/rfc/rfc2193.txt 

2195 IMAP/POP AUTHorize Extension for 

Simple Challenge/Response 

http://www.ietf.org/rfc/rfc2195.txt RFC 2095 

2221 IMAP4 Login Referrals http://www.ietf.org/rfc/rfc2221.txt 

2342 IMAP4 Namespace http://www.ietf.org/rfc/rfc2342.txt 

2595 Using TLS with IMAP, POP3 and ACAP http://www.ietf.org/rfc/rfc2595.txt 

2683 IMAP4 Implementation Recommendations http://www.ietf.org/rfc/rfc2683.txt 

2971 IMAP4 ID extension http://www.ietf.org/rfc/rfc2971.txt 

3348 The Internet Message Action Protocol 

(IMAP4) Child Mailbox Extension 

http://www.ietf.org/rfc/rfc3348.txt 

3501 Internet Message Access Protocol - Version 

4rev1 

http://www.ietf.org/rfc/rfc3501.txt RFC 2060 

3502 Internet Message Access Protocol (IMAP) – 

MULTIAPPEND Extension 

http://www.ietf.org/rfc/rfc3502.txt 

3503 Message Disposition Notification (MDN) 

profile for Internet Message Access Protocol 

(IMAP) 

http://www.ietf.org/rfc/rfc3503.txt 

3516 IMAP4 Binary Content Extension http://www.ietf.org/rfc/rfc3516.txt 

3691 Internet Message Access Protocol (IMAP) 

UNSELECT command 

http://www.ietf.org/rfc/rfc3691.txt 

4314 IMAP4 Access Control List (ACL) 

Extension 

http://www.ietf.org/rfc/rfc4314.txt RFC 2086 
Guidelines on Electronic Mail Security (Draft) 

B-6 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

4315 Internet Message Access Protocol (IMAP) - 

UIDPLUS extension 

http://www.ietf.org/rfc/rfc4315.txt RFC 2359 

MIME and S/MIME RFCs by RFC Number

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

2015 MIME Security with Pretty Good Privacy 

(PGP) 

http://www.ietf.org/rfc/rfc2015.txt 

2045 Multipurpose Internet Mail Extensions 

(MIME) Part One: Format of Internet 

Message Bodies 

http://www.ietf.org/rfc/rfc2045.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2046 Multipurpose Internet Mail Extensions 

(MIME) Part Two: Media Types 

http://www.ietf.org/rfc/rfc2046.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2047 MIME (Multipurpose Internet Mail 

Extensions) Part Three: Message Header 

Extensions for Non-ASCII Text 

http://www.ietf.org/rfc/rfc2047.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2049 Multipurpose Internet Mail Extensions 

(MIME) Part Five: Conformance Criteria 

and Examples 

http://www.ietf.org/rfc/rfc2049.txt RFC 1521, 

RFC 1522, 

RFC 1590 

2268 A Description of the RC2 Encryption 

Algorithm 

http://www.ietf.org/rfc/rfc2268.txt 

2311 S/MIME Version 2 Message Specification http://www.ietf.org/rfc/rfc2311.txt 

2312 S/MIME Version 2 Certificate Handling http://www.ietf.org/rfc/rfc2312.txt 

2313 PKCS #1: RSA Encryption Version 1.5 http://www.ietf.org/rfc/rfc2313.txt 

2314 PKCS #10: Certification Request Syntax 

Version 1.5 

http://www.ietf.org/rfc/rfc2314.txt 

2315 PKCS #7: Cryptographic Message Syntax 

Version 1.5 

http://www.ietf.org/rfc/rfc2315.txt 

2630 Cryptographic Message Syntax http://www.ietf.org/rfc/rfc2630.txt 

2632 S/MIME Version 3 Certificate Handling http://www.ietf.org/rfc/rfc2632.txt 

2633 S/MIME Version 3 Message Specification http://www.ietf.org/rfc/rfc2633.txt 

2634 Enhanced Security Services for S/MIME http://www.ietf.org/rfc/rfc2634.txt 

3156 MIME Security with OpenPGP http://www.ietf.org/rfc/rfc3156.txt RFC 2015 

(updates) 

4141 SMTP and MIME Extensions for Content 

Conversion 

http://www.ietf.org/rfc/rfc4141.txt 

4289 Multipurpose Internet Mail Extensions 

(MIME) Part Four: Registration Procedures 

http://www.ietf.org/rfc/rfc4289.txt RFC 2048 
Guidelines on Electronic Mail Security (Draft) 

B-7 

OpenPGP and PGP-Related RFCs by RFC Number

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

1991 PGP Message Exchange Formats http://www.ietf.org/rfc/rfc1991.txt 

2015 MIME Security with Pretty Good Privacy 

(PGP) 

http://www.ietf.org/rfc/rfc2015.txt 

2440 OpenPGP Message Format http://www.ietf.org/rfc/rfc2440.txt 

3156 MIME Security with OpenPGP http://www.ietf.org/rfc/rfc3156.txt RFC 2015 

(updates) 

POP-Related RFCs by RFC Number 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

1939 Post Office Protocol - Version 3 http://www.ietf.org/rfc/rfc1939.txt RFC 1725 

1957 Some Observations on Implementations of 

the Post Office Protocol (POP3) 

http://www.ietf.org/rfc/rfc1957.txt RFC 1939 

(updates) 

2195 IMAP/POP AUTHorize Extension for 

Simple Challenge/Response 

http://www.ietf.org/rfc/rfc2195.txt RFC 2095 

2384 POP URL Scheme http://www.ietf.org/rfc/rfc2384.txt 

2449 POP3 Extension Mechanism http://www.ietf.org/rfc/rfc2449.txt RFC 1939 

(updates) 

2595 Using TLS with IMAP, POP3 and ACAP http://www.ietf.org/rfc/rfc2595.txt 

3206 The SYS and AUTH POP Response Codes http://www.ietf.org/rfc/rfc3206.txt 

SMTP-Related RFCs by RFC Number

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

1870 SMTP Service Extension for Message Size 

Declaration 

http://www.ietf.org/rfc/rfc1870.txt RFC 1653 

1985 SMTP Service Extension for Remote 

Message Queue Starting 

http://www.ietf.org/rfc/rfc1985.txt 

2034 SMTP Service Extension for Returning 

Enhanced Error Codes 

http://www.ietf.org/rfc/rfc2034.txt 

2442 The Batch SMTP Media Type http://www.ietf.org/rfc/rfc2442.txt 

2505 Anti-Spam Recommendations for SMTP 

MTAs 

http://www.ietf.org/rfc/rfc2505.txt 
Guidelines on Electronic Mail Security (Draft) 

B-8 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

2554 SMTP Service Extension for Authentication http://www.ietf.org/rfc/rfc2554.txt 

2645 On-Demand Mail Relay (ODMR) SMTP 

with Dynamic IP Addresses 

http://www.ietf.org/rfc/rfc2645.txt 

2821 Simple Mail Transfer Protocol http://www.ietf.org/rfc/rfc2821.txt RFC 821, 

RFC 974, 

RFC 1869, 

RFC 1123 

(updates) 

2822 Internet Message Format http://www.ietf.org/rfc/rfc2822.txt RFC 822 

2846 GSTN Address Element Extensions in Email Services http://www.ietf.org/rfc/rfc2846.txt 

2852 Deliver By SMTP Service Extension http://www.ietf.org/rfc/rfc2852.txt RFC 1894 

(updates) 

2920 SMTP Service Extension for Command 

Pipelining 

http://www.ietf.org/rfc/rfc2920.txt RFC 2197 

3030 SMTP Service Extensions for Transmission 

of Large and Binary MIME Messages 

http://www.ietf.org/rfc/rfc3030.txt RFC 1830 

3207 SMTP Service Extension for Secure SMTP 

over Transport Layer Security 

http://www.ietf.org/rfc/rfc3207.txt RFC 2487 

3461 Simple Mail Transfer Protocol (SMTP) 

Service Extension for Delivery Status 

Notifications (DSNs) 

http://www.ietf.org/rfc/rfc3461.txt RFC 1891 

3462 The Multipart/Report Content Type for the 

Reporting of Mail System Administrative 

Messages 

http://www.ietf.org/rfc/rfc3462.txt RFC 1892 

3463 Enhanced Mail System Status Codes http://www.ietf.org/rfc/rfc3463.txt RFC 1893 

3464 An Extensible Message Format for Delivery 

Status Notifications 

http://www.ietf.org/rfc/rfc3464.txt RFC 1894 

3798 Message Disposition Notification http://www.ietf.org/rfc/rfc3798.txt RFC 2298, 

RFC 2046 

(updates), 

RFC 3461 

(updates) 

3848 ESMTP and LMTP Transmission Types 

Registration 

http://www.ietf.org/rfc/rfc3848.txt 

3865 A No Soliciting Simple Mail Transfer 

Protocol (SMTP) Service Extension 

http://www.ietf.org/rfc/rfc3865.txt 

3885 SMTP Service Extension for Message 

Tracking 

http://www.ietf.org/rfc/rfc3885.txt RFC 3461 

(updates) 

3886 An Extensible Message Format for Message 

Tracking Responses 

http://www.ietf.org/rfc/rfc3886.txt RFC 3463 

(updates) 
Guidelines on Electronic Mail Security (Draft) 

B-9 

RFC 

No. 

RFC Title URL Replaced/ 

Updated 

3974 SMTP Operational Experience in Mixed 

IPv4/v6 Environments 

http://www.ietf.org/rfc/rfc3974.txt 

4141 SMTP and MIME Extensions for Content 

Conversion 

http://www.ietf.org/rfc/rfc4141.txt 
Guidelines on Electronic Mail Security (Draft) 

C-1 

Appendix C. References 

[CERT00] CERT, Securing Network Servers, 2000, 

http://www.sei.cmu.edu/pub/documents/sims/pdf/sim010.pdf 

[Curt01] Matt Curtin, Developing Trust: Online Privacy and Security, November 2001 

[NIST01] Rebecca Bace and Peter Mell, NIST Special Publication 800-31, Intrusion 

Detection Systems, August 2001, 

http://csrc.nist.gov/publications/nistpubs/index.html

[NIST02a] John Wack, et al., NIST Special Publication 800-41, Guidelines on Firewalls and 

Firewall Policy, January 2002, 

http://csrc.nist.gov/publications/nistpubs/index.html

[NIST02b] John Wack, et al., NIST Special Publication 800-42, Guideline on Network 

Security Testing, February 2002, 

http://csrc.nist.gov/publications/nistpubs/index.html

[NIST05] Peter Mell, et al., NIST Special Publication 800-83, Guide to Malware Incident 

Prevention and Handling, November 2005, 

http://csrc.nist.gov/publications/nistpubs/index.html 

[NIST06a] Marianne Swanson, et al, NIST Special Publication 800-18 Revision 1, Guide for 

Developing Security Plans for Federal Information Systems, February 2006, 

http://csrc.nist.gov/publications/nistpubs/index.html 

[NIST06b] Murugiah Souppaya and Karen Kent, NIST Special Publication 800-92 

(DRAFT), Guide to Computer Security Log Management, April 2006, 

http://csrc.nist.gov/publications/nistpubs/index.html 

[NSA01] Trent Pitsenbarger, Email Security in the Wake of Recent Malicious Code 

Incidents, 2001, http://www.nsa.gov/snac/ 

[NISS99] National Information System Security Glossary, NSTISSI No. 4009, January 

1999 

[PCMAG01] Ashley McKinnon, “Web and Email Filtering”, PC Magazine, December 2001 

[Salt75] Jerome H. Saltzer and Michael Schroeder, “The Protection of Information in 

Computer Systems,” Proceedings of the IEEE, Volume 63, pages 1278-1308
Guidelines on Electronic Mail Security (Draft) 

D-1 

Appendix D. Email Security Tools and Applications 

The lists below provide examples of tools and resources that may be helpful.60 

Centralized Malware Scanning and Content Filtering Applications 

Manufacturer Tools Web Site Linux/

Unix 

Win32 Cost 

Aladdin 

Knowledge 

Systems 

eSafe Gateway, eSafe 

Mail 

http://www.aladdin.com/esafe/email_secur

ity.asp 

9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, and SMTP-based mail servers. 

Barracuda 

Networks 

Barracuda Spam 

Firewall 

http://www.barracudanetworks.com/ns/pro

ducts/spam_overview.php 

$$$ 

Description Appliance-based solutions for monitoring email messages in transit; separate from mail servers. 

BorderWare 

Technologies 

MXtreme Mail Firewall http://www.borderware.com/products/mxtr

eme/ 

$$$ 

Description Appliance-based solutions for monitoring email messages in transit; separate from mail servers. 

CipherTrust CipherTrust Edge, 

CipherTrust IronMail 

http://www.ciphertrust.com/products/index

.php 

$$$ 

Description Appliance-based solutions for monitoring email messages in transit; separate from mail servers. 

Clearswift MIMEsweeper http://www.mimesweeper.com/ 9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, and SMTP-based mail servers. 

F-Secure F-Secure Anti-Virus, FSecure Internet 

Gatekeeper, F-Secure 

Messaging Security 

Gateway, F-Secure 

Spam Control, 

http://www.f-secure.com/products/antivirus/gw/index.shtml 

9 9 $$$ 

Description Supports Microsoft Exchange, SMTP, and POP3. 

GFI Software GFI MailEssentials, 

GFI MailSecurity 

http://www.gfi.com/mailsecurity/ 9 $$$ 

Description Supports Microsoft Exchange and SMTP-based mail servers.

GROUP 

Technologies 

iQ Suite http://www.groupsoftware.com/en/products/iq_suite/iq_suite

.php 

9 9 $$$ 

Description Supports Microsoft Exchange, Microsoft ISA, IBM Lotus Domino, and Microsoft SMTP-based mail servers.

IronPort 

Systems 

IronPort http://www.ironport.com/products/ $$$ 

Description Appliance-based solutions for monitoring email messages in transit; separate from mail servers.

 

60 The applications referenced in this appendix are by no means a complete list of applications to use for 

email security purposes, nor does this publication imply any endorsement of certain products. 
Guidelines on Electronic Mail Security (Draft) 

D-2 

Manufacturer Tools Web Site Linux/

Unix 

Win32 Cost 

Kaspersky 

Lab 

Kaspersky Anti-Spam, 

Kaspersky Anti-Virus, 

Kaspersky SMTPGateway 

http://usa.kaspersky.com/products/corporat

e-security.php 

9 9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, and SMTP-based mail servers (including Sendmail, qmail, 

Postfix, CommuniGate Pro, and Exim). 

MailScanner/

Julian Field 

MailScanner http://www.mailscanner.info/ 9

Description Typically used with SpamAssassin and ClamAV; supports various SMTP-based mail servers (including Postfix, 

Exim, and ZMailer) 

Marshal MailMarshal http://www.marshal.com/pages/products.as

p 

9 $$$ 

Description Supports Microsoft Exchange and SMTP servers. 

McAfee McAfee GroupShield, 

McAfee Secure 

Messaging, McAfee 

SpamKiller 

http://www.mcafee.com/us/enterprise/prod

ucts/anti_virus/email_servers/index.html 

9 9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, and SMTP-based mail servers. 

Mirapoint RazorGate http://www.mirapoint.com/products/ $$$ 

Description Appliance-based solutions for monitoring email messages in transit; separate from mail servers. 

Panda 

Antivirus 

EnterpriSecure http://www.pandasoftware.com/home/emp

resas/default 

9 9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, and SMTP-based mail servers (including Sendmail, Qmail, 

and Postfix). 

Proofpoint Proofpoint Messaging 

Security Gateway, 

Proofpoint Protection 

Server 

http://www.proofpoint.com/products/index

.php 

9 $$$ 

Description Supports SMTP-based mail servers. 

Sendmail Sendmail Mailstream, 

Sendmail Sentrion 

http://www.sendmail.com/products/ 9 9 $$$ 

Description Supports SMTP-based mail servers. 

SonicWALL SonicWALL Email 

Security 

http://www.sonicwall.com/products/emails

ecurity/index.html 

9 $$$ 

Description Supports Microsoft Exchange and SMTP-based mail servers. 

Sophos Sophos ES4000 Email 

Security Appliance, 

Sophos MailMonitor, 

Sophos PureMessage 

http://www.sophos.com/products/es/gatew

ay/ 

9 9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, and SMTP-based mail servers (including Sendmail, Postfix, 

Sun Java System Messaging Server, and SunOne Messaging Server). 

SurfControl SurfControl E-mail 

Filter, SurfControl 

RiskFilter 

http://www.surfcontrol.com/ 9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, GroupWise, Sendmail, and other SMTP-based mail servers. 
Guidelines on Electronic Mail Security (Draft) 

D-3 

Manufacturer Tools Web Site Linux/

Unix 

Win32 Cost 

Symantec Symantec AntiVirus, 

Symantec Mail Security 

http://www.symantec.com/enterprise/produ

cts/index.jsp 

9 9 $$$ 

Description Supports Microsoft Exchange, IBM Lotus Domino, and SMTP-based mail servers. 

Trend Micro ScanMail http://www.trendmicro.com/en/products/e

mail/overview.htm

9 9 $$$ 

Description Supports Microsoft Exchange and IBM Lotus Domino.

Tumbleweed 

Communicati

ons 

MailGate http://www.tumbleweed.com/products/mai

lgate/index.html 

9 $$$ 

Description Supports Microsoft Exchange and SMTP-based mail servers.

$$$=This product involves a fee. 

 Open Relay Tools 

Tool Capabilities Web Site Web-Based Cost 

Mail Relay Testing Tools 

DNSExit Mail 

Relay Testing 

Tool 

Mail Relay Tool https://www.dnsexit.com/Direct.sv?cmd=testMail

Server

9 Free 

Description Attempts to telnet into an email server at a specified SMTP port and deliver a message to that server. It will detect 

whether or not the email server is configured correctly. 

Mail Relay 

Testing Tool 

Mail Relay Tool http://abuse.net/relay.html 9 Free 

Description Assists administrators in identifying mail relays. 

Open Relay 

Database 

Mail Relay Tool http://www.ordb.org/ 9 Free 

Description Contains IP addresses of verified open SMTP relays. By accessing this list, system administrators are allowed to 

choose to accept or deny email exchange with servers at these addresses. 

Spam Relay 

Checker 

Spam Relay Tool http://www.3dmail.com/spam/ 9 Free 

Description Assists system administrators to trace spam sources in hopes of tracking from where the spam is being generated. 

It will assist in the notification to the Postmaster of the server that it is being misused by spammers. 

Blacklists61

Composite 

Blocking List 

(CBL) 

Blacklist http://cbl.abuseat.org/ 9 Free 

 

61 For additional blacklist resources, see http://dmoz.org/Computers/Internet/Abuse/Spam/Blacklists/. 
Guidelines on Electronic Mail Security (Draft) 

D-4 

Tool Capabilities Web Site Web-Based Cost 

Description The CBL takes its source data from very large spam traps, and only lists IPs exhibiting characteristics which are 

specific to open proxies of various sorts (HTTP, socks, AnalogX, wingate, etc.) which have been abused to send 

spam, worms and viruses that do their own direct mail transmission, or some types of Trojan horse or “stealth” 

spamware, without doing open proxy tests of any kind. 

Distributed 

Server 

Boycott List 

(DSBL) 

Blacklist http://dsbl.org/main 9 Free 

Description The DSBL lists contain the IP addresses of servers which have relayed special test messages to 

listme@listme.dsbl.org; this can happen if the server is an open relay, an open proxy, or has another vulnerability 

that allows anybody to deliver email to anywhere through that server. 

NJABL.ORG Blacklist http://njabl.org/ 9 Free 

Description NJABL.ORG maintains a list of known and potential spam sources (open relays, open proxies, open form to mail 

HTTP gateways, dynamic IP pools, and direct spammers) for the purpose of being able to tag or refuse email and 

prevent at least some spam. 

The 

Spamhaus 

Block List 

(SBL)

Blacklist http://www.spamhaus.org/sbl/ 9 Free 

Description The SBL is a real-time database of IP addresses of verified spam sources (including spammers, spam gangs, and 

spam support services), maintained by the Spamhaus Project team and supplied as a free service to help email 

administrators better manage incoming email streams.

MX Record Lookup 

DNS MX 

record lookup 

MX Record 

Lookup 

http://airlinknetworks.com/exchange/MXrecordL

ookup.html

9 Free 

Description This tool allows for lookup of a domain’s MX servers. 

Domain Mail 

Server/ 

Exchanger 

(MX Records) 

Lookup 

MX Record 

Lookup 

http://www.hashemian.com/tools/domainemail.php

9 Free 

Description This tool attempts to identify the mail servers used by a specified email address. This can be useful to check an 

email's authenticity, or check who handles email for a certain address. 

MX Record 

Lookup 

MX Record 

Lookup 

http://www.webmaster-toolkit.com/mx-recordlookup.shtml

9 Free 

Description The MX Record Lookup tool attempts to find out the mail servers used by a specified email address. This can be 

useful to check an email's authenticity, or check who handles email for a certain address. 
Guidelines on Electronic Mail Security (Draft) 

E-1 

Appendix E. Online Electronic Mail Security Resources 

This appendix contains lists of online resources that may be helpful to mail server administrators 

and others in achieving a greater understanding of mail security and in securing their mail servers, 

clients, and other mail system components. 

General Security Resources 

Resource/Title URL 

Center for Education and Research in 

Information Assurance and Security 

(CERIAS) 

http://www.cerias.purdue.edu/ 

CERT/CC http://www.cert.org/ 

Computer Security Resource Center 

(CSRC) 

http://csrc.nist.gov/ 

National Information Assurance 

Partnership (NIAP) 

http://www.niap.nist.gov/ 

National Vulnerability Database (NVD) http://nvd.nist.gov/ 

Office of Management and Budget 

Circular No. A-130 

http://www.whitehouse.gov/omb/circulars/a130/a130

trans4.html 

Open Source Vulnerability Database 

(OSVDB) 

http://www.osvdb.org/ 

RISKS Forum http://catless.ncl.ac.uk/Risks/ 

Security Configuration Checklists 

Program for IT Products 

http://checklists.nist.gov/ 

SecurityFocus Vulnerability Database http://www.securityfocus.com/vulnerabilities 

U.S. Computer Emergency Response 

Team (US-CERT) 

http://www.us-cert.gov/ 

U.S. Department of Energy Computer 

Incident Advisory Capability (CIAC) 

http://www.ciac.org/ciac/ 

General Mail and Mail Security Resources 

Resource/Title URL 

Email Issues, SANS Reading Room http://www.sans.org/rr/whitepapers/email/ 

Internet Mail Consortium http://www.imc.org/ 

The Tips and Tricks Guide to Secure 

Messaging 

http://www.microsoft.com/securemessaging/ebook/d

efault.mspx 
Guidelines on Electronic Mail Security (Draft) 

E-2 

Mail Encryption Resources 

Resource/Title URL 

Guide to Using S/MIME http://www.mozilla.org/projects/security/pki/psm/sm

ime_guide.html 

IETF OpenPGP Working Group http://www.ietf.org/html.charters/openpgpcharter.html 

IETF S/MIME Working Group http://www.ietf.org/html.charters/smime-charter.html

OpenPGP Alliance http://www.openpgp.org/ 

S/MIME Gateway Certification http://www.opengroup.org/smg/cert/ 

Securing Email Through Proxies: Smap 

and Stunnel 

http://rr.sans.org/email/smap.php 

Securing POP Mail on Windows 

Clients 

http://sewpsc.sewp.nasa.gov/documents/pop.mail.pdf

Securing POP Mail on Windows 

Clients 

http://csrc.nist.gov/fasp/FASPDocs/SecurPOPwSSH.

htm 

Malware and Spyware Resources 

Resource/Title URL 

Anti-Spyware Coalition (ASC) http://www.antispywarecoalition.org/ 

Anti-Virus Information Exchange Network 

(AVIEN) 

http://www.avien.org/ 

Common Malware Enumeration (CME) http://cme.mitre.org/ 

Computer Antivirus Research Organization 

(CARO) 

http://www.caro.org/ 

European Institute for Computer Antivirus 

Research (EICAR) 

http://www.eicar.org/ 

SecurityFocus Virus http://www.securityfocus.com/virus/ 

Spywaredata.com http://www.spywaredata.com/ 

Virus Bulletin http://www.virusbtn.com/ 

Viruslist.com http://www.viruslist.com/en/ 

WildList Organization International http://www.wildlist.org/ 
Guidelines on Electronic Mail Security (Draft) 

E-3 

Phishing Resources 

Resource/Title URL 

Anti-Phishing Working Group 

(APWG) 

http://www.antiphishing.org/ 

FTC, “How Not to Get Hooked by a 

‘Phishing’ Scam” 

http://ftc.gov/bcp/conline/pubs/alerts/phishingalrt.ht

m 

Internet Crime Complaint Center 

(ICCC) 

http://www.ic3.gov/ 

Phish Report Network http://www.phishreport.net/ 

Spam Resources 

Resource/Title URL 

Coalition Against Unsolicited 

Commercial Email (CAUCE) 

http://www.cauce.org/ 

Distributed Server Blackhole List 

(DSBL) 

http://www.dsbl.org/ 

Federal Trade Commission (FTC) 

Spam Home Page 

http://www.ftc.gov/spam/ 

GetNetWise http://spam/getnetwise.org/ 

Not Just Another Bogus List http://njabl.org/ 

OnGuard Online http://onguardonline.gov/index.html 

Open Relay Database http://www.ordb.org/ 

Spam.abuse.net http://spam.abuse.net/ 

Spamhaus http://www.spamhaus.org/ 

Spam Prevention Early Warning 

System (SPEWS) 

http://www.spews.org/ 

SPAM-L Mailing List Frequently 

Asked Questions (FAQ) 

http://www.claws-and-paws.com/spam-l 
Guidelines on Electronic Mail Security (Draft) 

E-4 

Mail Server Security Patch Resources 

Server/Manufacturer URL 

602LAN Suite 

(Software602) 

http://support.software602.com/updates/

ArGoSoft Mail Server 

(ArGoSoft) 

http://www.argosoft.com/rootpages/Download.aspx 

CommuniGate Pro (Stalker 

Software) 

http://www.stalker.com/CommuniGatePro/

Eudora Internet Mail Server 

(EIMS) (Glenn Anderson) 

http://www.eudora.co.nz/updates.html

Eudora WorldMail Server 

(Qualcomm) 

http://www.eudora.com/download/worldmail/

Exim (Exim) http://www.exim.org/

IMail Server (Ipswitch) http://www.ipswitch.com/support/imail/patch-upgrades.asp 

inFusion Mail Server 

(CoolFusion) 

http://www.coolfusion.com/downloads/

Kaspersky SMTP Gateway 

for UNIX (Kaspersky) 

http://www.kaspersky.com/productupdates/

Kerio MailServer (Kerio 

Technologies) 

http://www.kerio.com/subscription.html

Lotus Domino (IBM) http://www132.ibm.com/content/home/store_IBMPublicUSA/en_US/Upgra

des.html

MailEnable (MailEnable) http://www.mailenable.com/hotfix/default.asp

MailMax (Smartmax 

Software) 

http://www.smartmax.com/mmupgradecenter.aspx

MailSite (Rockliffe) http://www.rockliffe.com/userroom/download.asp

MDaemon (alt-n 

Technologies) 

http://www.altn.com/download/default.asp?product_id=MDaem

on

Merak Mail Server (Merak) http://www.merakmailserver.com/Download/

Microsoft Exchange 

(Microsoft) 

http://www.microsoft.com/technet/prodtechnol/exchange/downl

oads/2003/default.mspx 

Postfix (Wietse Venema) http://www.postfix.org/download.html

Sendmail (commercial 

version) (Sendmail, Inc.) 

http://www.sendmail.com/support/ 

sendmail (freeware version) 

(Sendmail Consortium) 

http://www.sendmail.org/

Xmail (Davide Libenzi) http://www.xmailserver.org/
Guidelines on Electronic Mail Security (Draft) 

E-5 

Mail Client Security Patch Resources 

Client/Manufacturer URL 

Balsa (GNOME Project) http://balsa.gnome.org/download.html 

Barca (Poco Systems) http://www.pocosystems.com/home/index.php?option=content&t

ask=category§ionid=2&id=21&Itemid=38 

Eudora (Qualcomm) http://www.eudora.com/download/ 

Eureka Email http://www.eureka-email.com/Download.html

GNUMail.app 

(Collaboration-world.com) 

http://www.collaboration-world.com/cgibin/project/release.cgi?pid=2

GyazMail (GyazSquare) http://www.gyazsquare.com/gyazmail/download.php

i.Scribe (Memecode 

Software) 

http://www.memecode.com/scribe.php

InScribe (Memecode 

Software) 

http://www.memecode.com/inscribe.php

KMail http://kmail.kde.org/download.html 

Mac OS X Mail (Apple) http://www.apple.com/support/panther/mail/ 

Mailsmith (Bare Bones 

Software) 

http://www.barebones.com/support/mailsmith/updates.shtml

Mercury Mail Transport 

System (David Harris) 

http://www.pmail.com/patches.htm

Mozilla http://www.mozilla.org/security/

Mutt http://www.mutt.org/download.html 

Nisus Email (Nisus 

Software) 

http://www.nisus.com/NisusEmail/FAQ.php?PHPSESSID=0ba9f

9639672d1fdf836a97f3ad29383#HowUpgradeOS9

Outlook (Microsoft 

Corporation) 

http://office.microsoft.com/en-us/officeupdate/default.aspx

Outlook Express (Microsoft 

Corporation) 

http://www.microsoft.com/downloads/search.aspx?displaylang=e

n&categoryid=7

Pegasus Mail (David 

Harris) 

http://www.pmail.com/patches.htm

Pine (University of 

Washington) 

http://www.washington.edu/pine/getpine/ 

PocoMail (Poco Systems, 

Inc.) 

http://www.pocosystems.com/home/ 

Sylpheed http://sylpheed.good-day.net/en/ 

Thunderbird (Mozilla) http://www.mozilla.com/thunderbird/ 

VM http://www.wonderworks.com/vm/download.html
Guidelines on Electronic Mail Security (Draft) 

E-6 

NIST Publications on System and Network Security62

Publication URL 

SP 800-18, Guide to Developing 

Security Plans for Information 

Technology Systems 

http://csrc.nist.gov/publications/nistpubs/800-18-

Rev1/sp800-18-Rev1-final.pdf 

SP 800-26, Security Self-Assessment 

Guide for Information Technology 

Systems 

http://csrc.nist.gov/publications/nistpubs/800-

26/sp800-26.pdf 

SP 800-27, Engineering Principles for 

Information Technology Security 

http://csrc.nist.gov/publications/nistpubs/800-

27A/SP800-27-RevA.pdf 

SP 800-28, Guidelines on Active 

Content and Mobile Code 

http://csrc.nist.gov/publications/nistpubs/800-

28/sp800-28.pdf 

SP 800-31, Intrusion Detection Systems http://csrc.nist.gov/publications/nistpubs/800-

31/sp800-31.pdf 

SP 800-32, Introduction to Public Key 

Technology and the Federal PKI 

Infrastructure 

http://csrc.nist.gov/publications/nistpubs/800-

32/sp800-32.pdf 

SP 800-34, Contingency Planning 

Guide for Information Technology 

Systems 

http://csrc.nist.gov/publications/nistpubs/800-

34/sp800-34.pdf 

SP 800-37, Federal Guidelines for the 

Security Certification and Accreditation 

of Information Technology Systems 

http://csrc.nist.gov/publications/nistpubs/800-

37/SP800-37-final.pdf 

SP 800-40v2, Creating a Patch and 

Vulnerability Management Program 

http://csrc.nist.gov/publications/nistpubs/800-40-

Ver2/SP800-40v2.pdf 

SP 800-41, Guide to Firewall Selection 

and Policy Recommendations 

http://csrc.nist.gov/publications/nistpubs/800-

41/sp800-41.pdf 

SP 800-42, Guideline on Network 

Security Testing 

http://csrc.nist.gov/publications/nistpubs/800-

42/NIST-SP800-42.pdf 

SP 800-43, Guide to Securing Windows 

2000 Professional 

http://csrc.nist.gov/itsec/guidance_W2Kpro.html 

SP 800-44, Guidelines on Securing 

Public Web Servers 

http://csrc.nist.gov/publications/nistpubs/800-

44/sp800-44.pdf 

SP 800-46, Security for Telecommuting 

and Broadband Communications 

http://csrc.nist.gov/publications/nistpubs/800-

46/sp800-46.pdf 

SP 800-52, Guidelines for the Selection 

and Use of Transport Layer Security 

Implementations 

http://csrc.nist.gov/publications/nistpubs/800-

52/SP800-52.pdf 

 

62 The primary Web site for all of these publications is located at http://csrc.nist.gov/publications/index.html. 
Guidelines on Electronic Mail Security (Draft) 

E-7 

Publication URL 

SP 800-53, Recommended Security 

Controls for Federal Information 

Systems 

http://csrc.nist.gov/publications/nistpubs/800-

53/SP800-53.pdf 

SP 800-61, Computer Security Incident 

Handling Guide 

http://csrc.nist.gov/publications/nistpubs/800-

61/sp800-61.pdf 

SP 800-63, Electronic Authentication 

Guideline 

http://csrc.nist.gov/publications/nistpubs/800-

63/SP800-63v6_3_3.pdf 

SP 800-68, Guidance for Securing 

Microsoft Windows XP Systems for IT 

Professionals 

http://csrc.nist.gov/itsec/download_WinXP.html 

SP 800-69, Guidance for Securing 

Microsoft Windows XP Home Edition: 

A NIST Security Configuration 

Checklist (DRAFT) 

http://csrc.nist.gov/itsec/guidance_WinXP_Home.ht

ml 

SP 800-83, Guide to Malware Incident 

Prevention and Handling

http://csrc.nist.gov/publications/nistpubs/800-

83/SP800-83.pdf 

SP 800-92, Guide to Computer Security 

Log Management (DRAFT) 

http://csrc.nist.gov/publications/drafts.html 
Guidelines on Electronic Mail Security (Draft) 

F-1 

Appendix F. Email Server and Client Security Checklists 

Securing the Mail Server Operating System 

Completed Action

Plan the configuration and deployment of mail server 

Identify functions of the mail server 

Identify categories of information that will be stored, processed, 

and transmitted through the mail server 

Identify security requirements of information 

Identify a dedicated host to run the mail server 

Identify network services that will be provided or supported by the 

mail server 

Identify users and categories of users of the mail server and 

determine privilege for each category of user 

Identify user authentication methods for the mail server 

Choose appropriate operating system for mail server 

Minimal exposure to vulnerabilities 

Ability to restrict administrative or root level activities to 

authorized users only 

Ability to deny access to information on the server other than that 

intended to be available 

Ability to disable unnecessary network services that may be built 

into the operating system or server software 

Acceptable costs for insurance and liability (some insurers charge 

more for certain operating systems) 

Availability of experienced staff to install, configure, secure, and 

maintain operating system 

Patch and upgrade operating system 

Identify and install all necessary patches and upgrades to the 

operating system 

Identify and install all necessary patches and upgrades to 

applications and services included with the operating system 

Remove or disable unnecessary services and applications 

Disable or remove unnecessary services and applications 

Configure operating system user authentication 

Remove or disable unneeded default accounts and groups 

Disable non-interactive accounts 

Create the user groups for the particular computer 
Guidelines on Electronic Mail Security (Draft) 

F-2 

Completed Action

Create the user accounts for the particular computer 

Check the organization’s password policy, and set account 

passwords appropriately (e.g., length, complexity) 

Configure computer to deny login after a limited number of failed 

attempts 

Install and configure other security mechanisms to strengthen 

authentication 

Configure resource controls appropriately

Set access controls for files, directories, devices, and other 

resources 

Limit privileges for most system-related tools to authorized 

system administrators 

Install and configure additional security controls

Select, install, and configure additional software to provide needed 

controls not included in the operating system 

Test the security of the operating system 

Test operating system after initial install to determine 

vulnerabilities 

Test operating system periodically (e.g. quarterly) to determine 

new vulnerabilities 

Mail Server and Content Security Checklist 

Completed Action

Hardening the mail server application 

Install the mail server software on a dedicated host 

Apply any patches or upgrades to correct for known 

vulnerabilities 

Create a dedicated physical disk or logical partition (separate from 

operating system and mail server application) for mailboxes, or 

host the mailboxes on a separate server 

Remove or disable all services installed by the mail server 

application but not required (e.g., Web-based mail, FTP, remote 

administration) 

Remove all manufacturer documentation from server 

Remove any example or test files from server 

Apply appropriate security template or hardening script to the 

server 
Guidelines on Electronic Mail Security (Draft) 

F-3 

Completed Action

Reconfigure SMTP, POP and IMAP service banners (and others 

as required) NOT to report mail server and operating system type 

and version. 

Disable dangerous or unnecessary mail commands (e.g., VRFY 

and EXPN)

Configuring operating system and mail server access controls 

Limit the access of the mail server application to a subset of 

computational resources 

Limit the access of users through additional access controls 

enforced by the mail server, where more detailed levels of access 

control are required 

Configure the mail server application to execute only under a 

unique individual user and group identity with restrictive access 

controls 

Ensure the mail server is not running with root or 

system/administrator privileges 

Configure the host operating system so that mail server can write 

log files but not read them 

Configure the host operating system so that temporary files 

created by mail server application are restricted to a specified and 

appropriately protected subdirectory 

Configure the host operating system so that access to any 

temporary files created by the mail server application is limited to 

the mail server processes that created these files 

Ensure that the mail server cannot save files outside of the 

specified files structure dedicated to the mail server 

Configure the mail server to run in a chroot jail on Linux and Unix 

hosts 

Install users’ mailboxes on a different server (preferred), hard 

drive, or logical partition than the operating system and mail 

server application 

Limit the size of attachments that are allowed 

Ensure log files are stored in a location that is sized appropriately 

Coping with harmful attachments and content 

Implement centralized malware scanning (on the firewall/mail 

relay/mail gateway and/or mail server, preferably both) 

Install malware scanners on all client hosts 

Update the signature databases of all malware scanning software 

on a daily basis or when there is a malware outbreak 

Educate users on the dangers of malware and how to minimize 

those dangers 

Notify users when an outbreak occurs 
Guidelines on Electronic Mail Security (Draft) 

F-4 

Completed Action

Configure content filtering to block or tag suspicious messages 

(e.g., phishing, spam) 

Configure content filtering to strip suspicious active content from 

messages 

Configure lexical analysis if required 

Create a content filtering policy 

Add legal disclaimer to emails, if required 

Configure mail gateways or firewalls to use LDAP lookup to 

confirm the existence of email recipients 

Configure mail server to block mail from open relay blacklists or 

DNS blacklists 

Configure mail server to block mail from specific domains, if 

required 

Configure authenticated mail relay on server 

Configure mail server to use encrypted authentication 

Configure mail server to support Web access only via SSL/TLS 

and only if such access is deemed necessary 

Network Infrastructure Checklist 

Completed Action

Network location 

Mail server is located on the internal network and protected by a 

mail gateway and/or firewall, or 

Mail server is located in a DMZ 

Firewall configuration 

Mail server is protected by a firewall 

Mail server, if it faces a higher threat or if it is more vulnerable, is 

protected by an application layer firewall 

Firewall controls all traffic between the Internet and the mail 

server 

Firewall blocks all inbound traffic to the mail server except TCP 

ports 25 (SMTP), 110 (POP3), 143 (IMAP), 398( LDAP), and 636 

(secure LDAP), if required 

Firewall blocks (in conjunction with the intrusion detection or 

prevention system) IP addresses or subnets that the IPS reports are 

attacking the organizational network 

Firewall notifies the network administrator or mail server 

administrator of suspicious activity through an appropriate means 
Guidelines on Electronic Mail Security (Draft) 

F-5 

Completed Action

Firewall provides content filtering (application layer firewall) 

Firewall is configured to protect against DoS attacks 

Firewall logs critical events 

Firewall and firewall operating system patched to latest or most 

secure level 

Intrusion prevention systems 

IPS configured to monitor traffic network traffic to and from the 

mail server after firewall 

IPS configured to monitor changes to critical files on mail server 

(host-based IPS or file-integrity checker) 

IPS blocks (in conjunction with the firewall) IP addresses or 

subnets that are attacking the organizational network 

IPS notifies the IPS administrator or mail server administrator of 

attacks through appropriate means 

IPS configured to maximize detection with an acceptable level of 

false positives 

IPS configured to log events 

IPS updated with new attack signatures frequently (e.g., on a daily 

basis) 

Host-based IPS configured to monitor the system resources 

available on the mail server host 

Network switches 

Network switches are used to protect against network 

eavesdropping 

Network switches are configured in high-security mode to defeat 

ARP spoofing and ARP poisoning attacks 

Network switches are configured to send all traffic on network 

segment to network-based IPS 

Mail Client (MUA) Security Checklist 

Completed Action

Patching and updating mail clients 

Update email client to newest or most secure version 

Apply any necessary patches to email client (in conformance with 

organizational polices and configuration management) 

Apply any necessary patches to Web browser (for email clients 

that are integrated with browser (e.g., Outlook) 

Configuring mail client security features 
Guidelines on Electronic Mail Security (Draft) 

F-6 

Completed Action

Disable automatic message preview 

Disable automatic opening of messages 

Disable automatic loading of pictures in messages 

Disable downloading and processing of active content (if 

appropriate) 

Enable anti-spam and anti-phishing features 

Reconfigure portable email clients, such as those on cell phones 

and PDAs, to improve their security 

Ensure that security policy supports the protection of portable 

email clients, such as requiring anti-virus software to be installed 

and enabled 

Configuring authentication and access

Enable secure authentication and access 

Disable ability of email client to store username and passwords 

Configure client to use encryption (TLS) for SMTP, POP, and 

IMAP communications 

Set restrictions on the selection of email addresses, such as 

ensuring they are unrelated to user account names 

Provide security for email message content (e.g., S/MIME, 

OpenPGP) 

Enable and install only absolutely necessary plug-ins from trusted 

sources 

Configure Web-based email access to only use 128-bit SSL/TLS 

connections 

Educate users on the vulnerabilities of Web-based email access 

Securing the mail client host operating system 

Keep the OS updated to the most secure patch level 

Configure the OS to allow only the appropriate user(s) to access 

locally stored messages and mail client configuration files 

Secure or remove Windows Script Host (Windows hosts only) 

Change the default action on files associated with the Windows 

Script Host from execute to edit (Windows hosts only) 

Ensure that the OS is configured to show full file extensions 

(Windows hosts only) 

Install an anti-virus application and configure it to scan incoming 

messages and attachments; also install an anti-spyware application 

if the anti-virus software does not offer robust anti-spyware 

capabilities 

Install a personal firewall if needed to protect the computer from 

unauthorized communications 
Guidelines on Electronic Mail Security (Draft) 

F-7 

Completed Action

Ensure the OS enforces the concept of least privilege because 

malicious code runs in the security context on which it was 

launched (i.e., the user’s access level) 

Ensure that critical components of the operating system are 

protected from malicious code 

Use a file encrypting system to protect the mail stored locally on 

the user’s hard drive (especially important for laptop computers) 

Configure the OS to automatically lock the current session after a 

fixed period of inactivity 

Securely Administering a Mail Server Checklist 

Completed Action

Logging 

Log IP stack setup errors 

Log resolver configuration problem (e.g., DNS, NIS) 

Log mail server configuration errors (e.g., mismatch with DNS, 

local configuration error, out-of-date alias database) 

Log out of date alias databases 

Log lack of system resources (e.g., disk space, memory, CPU) 

Log alias database rebuilds 

Log logons (successful and failed) 

Log security problems (e.g., spamming) 

Log lost communications (network problems) 

Log protocol failures 

Log connection timeouts 

Log connection rejections 

Log use of VRFY and EXPN commands 

Log send on behalf of 

Log send as 

Log malformed addresses 

Log message collection statistics 

Log creation of error messages 

Log delivery failures (permanent errors) 

Log messages being deferred (transient errors) 

Store logs on a separate logging server 

Archive logs according to organizational requirements 
Guidelines on Electronic Mail Security (Draft) 

F-8 

Completed Action

Review logs daily 

Review logs weekly (for more long-term trends) 

Use automated log file analysis tool(s) 

Mail server backups 

Create a mail server backup policy 

Back up mail server differentially or incrementally on a daily to 

weekly basis 

Back up mail server fully on a weekly to monthly basis 

Periodically archive backups 

Recovering from a compromise 

Report incident to organization’s computer incident response 

capability 

Isolate compromised system(s) or take steps to contain attack so 

additional evidence can be collected 

Consult, as appropriate, with management, legal counsel, and law 

enforcement officials expeditiously 

Investigate similar hosts to determine if the attacker has also 

compromised other systems 

Analyze the intrusion 

Restore the system 

Test system to ensure security 

Reconnect system to network 

Monitor system and network for signs that the attacker is 

attempting to access the system or network again 

Document lessons learned 

Security testing 

Periodically conduct vulnerability scans on mail server and 

supporting network 

Update vulnerability scanner before testing 

Correct any deficiencies identified by the vulnerability scanner 

Conduct penetration testing on the mail server and the supporting 

network infrastructure 

Correct deficiencies identified by penetration testing 

Remote administration 

Use a strong authentication mechanism (e.g., public/private key 

pair, two factor authentication) 

Restrict hosts that can be used to remotely administer on the mail 

server by IP address and to the internal network 
Guidelines on Electronic Mail Security (Draft) 

F-9 

Completed Action

Use secure protocols (e.g., SSH, HTTPS) 

Enforce the concept of least privilege on remote administration 

(i.e., attempt to minimize the access rights for the remote 

administration/update accounts) 

Change any default accounts or passwords for the remote 

administration utility or application 

Do not allow remote administration from the Internet unless 

mechanisms such as VPN are used 
Guidelines on Electronic Mail Security (Draft) 

G-1 

Appendix G. Acronym List 

3DES Triple Data Encryption Standard 

ACL Access Control List 

AES Advanced Encryption Standard 

API Application Programming Interface

ARP Address Resolution Protocol 

ARPA Advanced Research Project Agency 

ASCII American Standard Code of Information Interchange 

CA Certificate Authority 

CIO Chief Information Officer 

CMVP Cryptographic Module Validation Program 

CPU Central Processing Unit 

CRAM Challenge-Response Authentication Mechanism 

CSE Communications Security Establishment 

DES Data Encryption Standard 

DMZ Demilitarized Zone 

DNS Domain Name System 

DNSBL Domain Name System Blacklist 

DoD Department of Defense 

DoS Denial of Service 

DSA Digital Signature Algorithm 

DSN Delivery Status Notification 

DSS Digital Signature Standard 

ESMTP Extended Simple Mail Transfer Protocol 

FIPS Federal Information Processing Standards 

FISMA Federal Information Security Management Act 

FTP File Transfer Protocol 

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol 

HTTPS Hypertext Transfer Protocol Secure 

IBE Identity-Based Encryption 

IDP Intrusion Detection and Prevention 

IDS Intrusion Detection System 

IETF Internet Engineering Task Force 

IIS Internet Information Server 

IMAP Internet Message Access Protocol 

IP Internet Protocol 

IPS Intrusion Prevention System 

IPsec Internet Protocol Security 

ISP Internet Service Provider 

ISSO Information Systems Security Officer 

IT Information Technology 
Guidelines on Electronic Mail Security (Draft) 

G-2 

ITL Information Technology Laboratory 

LAN Local Area Network 

LDA Local Delivery Agent 

LDAP Lightweight Directory Access Protocol 

MD5 Message Digest 5 

MIME Multipurpose Internet Mail Extensions 

MOSS MIME Object Security Services 

MTA Mail Transfer Agent

MUA Mail User Agent 

NARA National Archives and Records Administration 

NetBIOS Network Basic Input/Output System

NFS Network File System 

NIS Network Information System

NIST National Institute of Standards and Technology 

NSA National Security Agency 

NVD National Vulnerability Database 

OMB Office of Management and Budget 

OpenPGP Open Pretty Good Privacy 

ORB Open Relay Blacklist 

OS Operating System 

PC Personal Computer 

PDA Personal Digital Assistant 

PEM Privacy Enhanced Mail 

PGP Pretty Good Privacy 

PKCS Public Key Cryptography Standard 

PKI Public Key Infrastructure 

POP Post Office Protocol 

RAID Redundant Array of Inexpensive Disks 

RFC Request for Comments 

SAISO Senior Agency Information Security Officer 

SHA-1 Secure Hash Algorithm-1 

SHS Secure Hash Standard 

SIEM Security Information and Event Management 

S/MIME Secure Multipurpose Internet Mail Extensions

SMTP Simple Mail Transfer Protocol 

SNMP Simple Network Management Protocol 

SOHO Small Office Home Office 

SP Special Publication 

SSH Secure Shell 

SSL Secure Sockets Layer 

TCP Transmission Control Protocol 

TCP/IP Transmission Control Protocol/Internet Protocol 

TLS Transport Layer Security 
Guidelines on Electronic Mail Security (Draft) 

G-3 

UCE Unsolicited Commercial Email 

UDP User Datagram Protocol 

U.S. United States 

VBScript Visual Basic Script 

VLAN Virtual Local Area Network 

VPN Virtual Private Network 

WSC Windows Script Component 

WSF Windows Script File 

WSH Windows Scripting Host 

WWW World Wide Web 
Guidelines on Electronic Mail Security (Draft) 

INDX-1 

Index 

Access control, 36, 41, 73, 81 

Access control list (ACL), 59 

Active content, 44, 50, 71 

Address Resolution Protocol (ARP), 69 

Advanced Encryption Standard (AES), 15, 18 

Anti-spyware software, 37, 44 

Anti-virus software, 37, 43, 44 

Application proxy, 44 

Attachment, 42, 49, 50, 74 

Authentication, 12, 34, 53, 72, 76 

Availability, 26 

Base64 encoding, 6 

Certificate authority (CA), 20, 21 

Certification and accreditation, 27 

Challenge-Response Authentication 

Mechanism (CRAM), 11 

Chief Information Officer (CIO), 24 

Compromise, 85 

Confidentiality, 26, 36 

Configuration control, 26 

Content filtering, 14, 49, 51, 65 

Contingency planning, 27 

Continuity of operations planning, 25, 27 

Cryptographic hash, 10, 14 

Cryptographic Module Validation Program 

(CMVP), 16 

Cryptography 

Public key, 14, 17 

Symmetric key, 14, 17 

Data Encryption Standard (DES), 15, 18 

Defense in depth, 30 

Demilitarized zone (DMZ), 59 

Denial of service (DoS), 65 

Digital signature, 14, 17 

Digital Signature Algorithm (DSA), 16 

Directory services, 33 

Disaster recover planning, 27 

DNS blacklist (DNSBL), 53 

Domain name system (DNS), 5 

Encryption, 12, 14 

Encryption algorithm, 19 

Encryption key management, 20 

Extended Simple Mail Transfer Protocol 

(ESMTP), 8 

Federal Information Processing Standards 

(FIPS), 16 

Federal Information Processing Standards 

(FIPS) Publication 140-2, 15, 18 

File integrity checker, 67 

Firewall, 37, 58 

Group, 34, 41 

HTML, 6 

Human resource, 28 

Hypertext Transfer Protocol (HTTP), 12 

Identity-based encryption (IBE), 20 

Incident response, 25, 85 

Information Systems Security Officers (ISSO), 

25 

Information Systems Security Program 

Managers (ISSM), 25 

Integrity, 26, 36, 82 

Internet Message Access Protocol (IMAP), 9, 

11, 12, 22, 40, 54, 59, 63, 64, 72, 73, 76, 5 

Intrusion, 85 

Intrusion detection, 37, 65, 66 

Intrusion prevention, 66 

Least privilege, 29 

Lightweight Directory Access Protocol 

(LDAP), 33, 63 

Local delivery agent (LDA), 5, 6, 9 

Logging, 42, 63, 64, 65, 79 

Analysis tool, 82 

Configuration, 79 

Log file review, 81 

Mail account, 4 

Mail client, 9 

Patches, 71 

Plug-in, 76 

Security, 71 

Mail gateway, 61 

Mail relay, 44, 53 

Mail server, 5, 31 

Backup procedures, 82 

Configuration, 8, 26 

Deployment plan, 22 

Hardening, 40 

Location, 58 

Management, 22 

Planning, 22 

Remote administration, 89 

Security, 29 

Security administration, 79 

Security testing, 87 

Mail server administrator, 23, 25 
Guidelines on Electronic Mail Security (Draft) 

INDX-2 

Mail transfer agent (MTA), 4, 6 

Proprietary, 9 

Mail user agent (MUA), 4, 7, 8, 9 

Mailbox, 9, 40, 42, 56, 2 

Mailbox access protocol, 9, 13 

Proprietary, 12 

Malware, 14, 37, 42, 44, 74 

Malware scanning, 45, 49, 59, 65 

MD5, 12 

Message 

Attachment, 5, 6 

Body, 4 

Composition, 4 

Compression, 17 

Delivery, 4 

Filtering, 5 

Header, 4 

Storage, 4 

MIME Object Security Services (MOSS), 14 

Multipurpose Internet Mail Extensions 

(MIME), 5 

Multipurpose Internet Mail Extensions 

(MIME), 6 

National Vulnerability Database (NVD), 32, 71 

Network administrator, 25 

Network infrastructure, 58 

NIST, iv 

Open Pretty Good Privacy (OpenPGP), 14, 15, 

19, 20, 75, 76, 79, 7 

Plug-in, 17 

Open relay blacklist (ORB), 53 

Operating system, 23 

Configuration, 33, 34 

Patching, 32 

Security, 31 

Security testing, 37 

Password, 35 

Patching, 32, 37, 40, 58, 87 

Penetration testing, 37, 87, 89 

Phishing, 44 

Physical security, 24 

Post Office Protocol (POP), 10, 11, 12, 22, 40, 

54, 59, 63, 64, 72, 73, 76, 7 

Post Office Protocol (POP), 9 

Pretty Good Privacy (PGP), 15, 7 

Privacy Enhanced Mail (PEM), 6, 14 

Public Key Cryptography Standard (PKCS), 

17 

Public key infrastructure (PKI), 21 

RC2, 18 

Recovery, 85 

RFC 

1421, 6 

1425, 8 

1651, 8 

1869, 8 

1939, 10 

1991, 15 

2045, 6 

2046, 6 

2047, 6 

2048, 6 

2049, 6 

2268, 18 

2311, 17 

2312, 17 

2313, 17 

2314, 18 

2315, 18 

2440, 15 

2449, 10 

2554, 8 

2595, 54 

2631, 18 

2634, 18 

2821, 7, 8 

2822, 4, 5, 6 

3156, 15 

3501, 11 

3850, 18 

3851, 18 

3852, 18 

4289, 6 

821, 7 

918, 10 

Risk assessment, 26 

Risk management, 26 

Rootkit detector, 37 

Router, 58 

RSA, 16 

Secure Hash Algorithm (SHA), 16 

Secure Multipurpose Internet Mail Extensions 

(S/MIME), 14, 17, 19, 20, 75, 76, 79, 6 

Secure Sockets Layer (SSL), 54, 55, 73, 76 

Security configuration checklist, 31 

Security controls 

Management, 28 

Operational, 28 

Technical, 28 

Security information and event management 

(SIEM) software, 82 

Security policy, 25, 26, 87 

Security requirements, 25 

Security testing, 25 

Security training, 27 

Sendmail, 54 

Senior IT management, 24 

Separation of privilege, 29 

Services, 33, 40 

Simple Mail Transfer Protocol (SMTP), 6, 12, 

22, 40, 44, 53, 54, 59, 63, 64, 73, 7 
Guidelines on Electronic Mail Security (Draft) 

INDX-3 

Commands, 7, 8 

Extensions, 6, 8 

Servers, 8 

Skills, 28 

Spam, 50, 52 

Standards, 4, 6 

Switch, 68, 69 

System identification, 28 

System security plan, 27, 28 

Telnet, 7 

Transport Layer Security (TLS), 12, 54, 55, 73, 

76 

Triple Data Encryption Standard (3DES), 15, 

18 

Unsolicited commercial email (UCE), 52 

Upgrades, 87 

User account, 34, 41 

Vulnerability scanner, 87 

Vulnerability scanning, 37, 87 

Web browser, 71 

Web of trust, 20 

Web server, 33 

Web-based mail access, 23, 31, 76, 89 

Web-based mail client, 12 

X.509, 17