This document provides an overview of electronic mail and email delivery systems. It discusses the basic roles of the Mail User Agent (MUA), Mail Delivery Agent (MDA), and Mail Transport Agent (MTA) in processing and delivering emails. It also covers common email protocols, the two primary models for email management ("every host" and "smart hub/thin client"), considerations for choosing an MTA like Sendmail, and key configuration files and variables used to customize Sendmail behavior.

1. Electronic Mail
Chapter 22

2. Chapter Goals
• Understand the basic steps in the mail delivery system.
– Understand the role of the Mail User Agent (MUA)
– Understand the role of the Mail Transport Agent (MTA)
• Understand the basic strategies for handling email.
• Understand the basic protocols used to deliver and transport mail.
• Understand the basics of email security
• Understand the basics of sendmail configuration and rulesets.
– Parsing
– Anti-spam
– Anti-relay
– Authentication

3. Email
• Email Overview
– Email is a “vital” service in users eyes.
• Lost mail is not acceptable
– But it happens daily!
• Email is assumed to be confidential
– It is not confidential!
• Email delivery delays are not tolerated
– Email is an unreliable service!
– This leaves system administrators with huge problems.
• How to ensure reliable service
• How to secure the MTA/SMTP service
• How to monitor and manage email services
• How to secure MUA services

4. Email
• Email Overview
– Typical user complaints/questions:
• How do I send mail to my friend? I don’t know
their address, but I need to send them mail.
• I sent person X mail, why don’t they respond?
• Why do I get all of this spam?
• Why can’t you stop all of this spam?
• Is OIT reading my mail?
• Where did my mail go? It was there a minute
ago!

5. Email
• Mail Overview (at the sending end)
– A user creates a mail message using a mail user agent (MUA)
(pine, mh, elm, netscape, eudora, mailx).
– When done “creating”, they exit the MUA.
– The MUA “contacts” a local mail delivery agent (MDA).
– The MDA spools the message in the mail spool area and
signals a program to process it.
– The program that processes the message is called a Mail
Transport Agent (MTA). The MTA implements the Simple Mail
Transfer Protocol (SMTP).
– The MTA parses the “To:” address, and attempts to contact
the remote host’s MTA.
• If contact succeeds, the local MTA transfers the mail to the
remote end.
• If contact fails, the local MTA retries for some finite period of
time.

6. Email
• Mail Overview (At the destination end)
– The destination MTA “receives” the message as per the
SMTP protocol
• sending end introduces itself
• sending end tells who mail is from
• sending end tells who mail is for
– If destination user is valid, open a spool, and continue
collection. More on this in a minute…
• Sending end transfers data
• Sending end closes connection

7. Email
• Mail Overview (”deliver it”)
– The destination MTA checks the “To:” address to
see if there is a system wide alias for the user.
• If alias exists, deliver as per alias.
• If no alias, check to see if account exists.
» If no account, reject message.
• If account exists, check to see if the user has a
.forward file.
– If .forward exists, deliver mail as per .forward
– If no .forward, deliver to local spool.
– When recipient invokes their MUA, it checks local
spool, and informs user there is a message.

8. Email
• Mail Aliases
– Unix: /etc/mail/aliases – a text file containing a list of recipients,
and names of users to deliver mail to.
root: curt, mmcnally
postmaster: root
epadmin: curt
cfh: curt
erp: curt, mark@co.org, jkeane@nd.edu
mentor: suggest, henry
tou: tou@cse.nd.edu
scott: scott@cse.nd.edu

9. Email
• Mail Strategy
– To implement the delivery of e-mail at a site, the
administrator has to make a few decisions about
how mail will be handled at the site.
• There are two primary e-mail models in use:
– the “every host” (mail host) model and
– the “smart-hub/thin-client” model.

10. Email
• Mail Strategy
– “Every Host” Mail host
• In this model, every machine on the network is
capable of sending and receiving e-mail. Although
this requires the least setup, it also causes problems.
– The administrator should add the mail spool to the
backup schedule to ensure that a user’s messages
are not lost.
– The individual machines are all running the SMTP
daemon, and could be used as open relays.
– The fact that e-mail does not pass to a single host
means that router filters and spam/virus filtering
are more difficult to implement.
– Troubleshooting mail problems is difficult, as every
machine is (potentially) configured differently.

11. Email
• Mail Strategy
– “Every Host” Mail host
– Every time a new version of the software is
released, the administrator has to update every
host.
– The good side of this model is that the
configuration is pretty minimal.
» Clients read mail from their own local disk, and
therefore the mail file system does not have to be
made available to other hosts.
» The administrator may have to develop a standard
delivery configuration file, and distribute it to all
machines.

12. Email
• Mail Strategy
– Smart Hub/Thin Client
• This model of e-mail management requires a large central e-mail
server.
– The central server is the only machine that will accept mail
messages for the entire enterprise.
– This server is configured with plenty of disk space and
connectivity to allow it to keep up with the load of all e-mail
into and out of the enterprise.
– If the enterprise decides to implement this model, the name
service may also require some reconfiguration, to add MX
records for all hosts in the enterprise.
– The MX record would tell other hosts to send their mail
messages to the smart hub, instead of to individual hosts
within the enterprise.

13. Email
• Mail Strategy
• This model requires much more configuration at the
beginning, but it also brings a certain amount of sanity
to the e-mail process.
– For example, the enterprise router filters may be tuned such
that they only allow SMTP connections to the mail hub (mail
server).
– All other SMTP connection requests can be denied.
– Anti spam/virus filtering can be installed on the mail server to
ensure that all messages are checked for harmful content.
– The administrator only has to back up one mail host, instead
of backing up the mail spool from every host at the
corporation.
– If an upgraded version of the mail software is released, the
operator has to update only one mail server, instead of
hundreds.

14. Email
• Mail Strategy
• Mail client machines can also be greatly simplified
using the mail hub model.
– For example, you might determine that it is not necessary to
run the SMTP daemon on client machines.
– A simple cron job to check the queue periodically and
process pending requests by sending them to the mail server
for delivery may be all the client support your site requires.
– For slightly more complicated scenarios, you may still need
to build an SMTP daemon configuration file to control this
process, and/or find a way to make the mail spool (on the
server) available to the MUAs on mail clients.

15. Email
• Mail Strategy
– But the news is not all good, as this model also has its downside.
• The mail server is a great repository of mail messages, but
it also has to make these messages available to users.
– Although you could force the user to log in to the mail
server to read mail, this is rarely acceptable.
– Another problem with the mail hub model is user
education.
» Users like to personalize their mail.
» Many users prefer to think that by having mail delivered
to their desktop, it is more secure.
» Some users want correspondents to think the mail goes
directly to their desktop, instead of to a corporate mail
server.
» Quite often, the administrator has to convince the user to
advertise the e-mail address on the corporate server,
rather than the address on the user’s desktop.

16. Email
• Mail Strategy
• Mail Servers often require substantial hardware to
implement this mail management model.
– A 20,000-employee operation could easily swamp
a four-processor mail hub with 300 gigabytes of
disk space reserved for the mail spool area.
– If that single mail server ever experiences a
problem that takes it off-line for an extended period
of time, the users will be on the warpath!

17. Email
• Email Protocols
– The heart of e-mail is the collection of protocols used to
transport e-mail from server to server and make it
available to users.
– This collection of standard protocols allows the wide
range of e-mail software to interoperate across the
Internet.
– These protocols can be split into three categories:
• those used by MTAs as mail is moved between servers,
• those used by MDAs to deliver the mail, and
• those used by MUAs to allow the user to read, create, and reply
to mail.

18. Email
• Email Protocols
– MUAs typically allow the user several methods of
accessing mail, depending on how and where messages
are stored.
• The three most common access methods are
– plain files,
– the Post Office Protocol (POP), and
– the Internet Mail Access Protocol (IMAP).
– These protocols, as well as the SMTP protocol used by
MTAs and associated service daemons, have their own
reserved ports

19. Email
• Mail User Agents (MUA’s)
– Some MUA’s “read” mail directly from the spool
(/var/mail, /var/spool/mail). (mailx)
• Mail spool must be mounted on machine where user
reads mail.
– Some MUA’s move messages to an Inbox and operate
on it there (pine, netscape).
• Mail spool must be accessible, but not necessarily
mounted on machine where user reads mail.

20. Email
• Mail User Agents (MUA’s)
– Some MUA’s use delivery protocols to get mail to
user
• Post Office Protocol (POP)
– Network based – cleartext passwords – copies mail to
client, can remove from server, or leave copy on server
(pointer into spool tells what has been read)
• Internet Mail Access Protocol (IMAP)
– Network based – cleartext passwords – uses RPC’s to
act on messages. Displays message on client, does
not copy to local disk.

21. Email
• MUA’s
– Have their own transport languages.
• Typical commands:
– User
– Pass
– Get
– Put
– Delete
– Purge
– Write (Save)

22. Email
• Mail transport agents (MTAs)
– Mail transport agents (MTAs) are the workhorses
of the e-mail system.
• Several MTAs exist for a wide range of platforms.
Some common choices are Sendmail, Microsoft’s
Exchange Server (exchange), postfix, qmail, and
exim, PMDF.
• This variety of choices means that the administrator
needs to make a decision as to which MTA will work
the best for the site.

23. Email
• Mail transport agents (MTAs)
• Many factors influence the MTA selection process,
including the following.
– Security is one of the primary factors in choosing an MTA.
Like a web server, a mail server will need to accept input
from a wide variety of sources, including malicious sources.
– A mail server needs to be capable of handling a large volume
of data.
– A mail server should be capable of using encrypted
connections.
– A mail server should be capable of controlling access.
• Sendmail is the most commonly used MTA. It is
shipped as the default MTA on nearly every UNIX
variant and is available for Windows.

24. Email
• Sendmail
– Sendmail, Inc. distributes an open-source version of the sendmail
MTA.
– The sendmail MTA is configurable on two fronts:
• The Build utilities (shipped with sendmail) allow the administrator
to configure the operation of the sendmail binary (email strategy,
security).
• The sendmail.cf file is used to customize the local delivery rules.

25. Email
• Sendmail Philosophy
• Don’t actually deliver email – route it.
– Too many local conventions.
– Too hard to customize sendmail to fit these conventions.
• Generalized crossbar switch
– Individual MUA’s don’t need to know where mail goes.
– All knowledge about mail routing is in SMTP daemon.
– All routing is consistent.
• Do some protocol conversion
– Basic header munging
• Do whatever is necessary to route message
– Better to deliver twice, than not at all
• Implemented via binary (typically /usr/lib/sendmail)
– Main configuration file: /etc/[mail]/sendmail.cf)

26. Email
• SMTP protocol (spoken by MTA’s)
– HELO/EHELO – introduce yourself, and your capabilities
– MAIL FROM – who is this message from?
– RCPT TO – who is this message to?
– DATA – what is the body of the message?
– VRFY – see if this user exists.
– EXPN – expand this address and tell me who it is
– HELP – display the sendmail.hf file
– RSET – reset the connection
– NOOP – do nothing
– VERB – verbose mode
– DSN – delivery status notice
– AUTH – authenticate this user
– QUIT – close the connection

27. Email
• Under the hood of MTA’s
– The SMTP daemon places the “message” in an
envelope for delivery.
• There is a header on the “letter”
• There is a header on the envelope.
• The headers contain addresses, and other information about the
message.
– They should be the same, but are not always!
» Envelope headers are (usually) assigned by system
software (SMTP)
» Message headers can be (and are) easily forged by
user.

28. Email
• Under the hood of MTA’s
• Users typically do not see the envelope.
– These headers are stripped off by the SMTP
daemon.
• Every message is assigned a unique ID by EACH SMTP daemon
that touches it.
– This allows tracing the message from end to end (if
log files are available).

29. Email
• The following are the files typically used to configure and support the
Sendmail binary.
– sendmail.mc: List of macro definitions used to create the
sendmail.cf file.
– sendmail.cf: Master Sendmail configuration file. It contains the
rules that parse mail messages, and determine how, and if, a
message gets delivered.
– sendmail.cw: Contains a list of hosts the mail server will accept
messages for.
– sendmail.hf: Contains help information for the SMTP daemon.
– sendmail.pid: Contains the process ID of the running Sendmail
daemon.
– aliases: Contains e-mail aliases (addresses) for users on this mail
server.
– access.db: Contains a database of sites/hosts/users that are, or are
not, allowed to access this mail server.

30. Email
• Parts of a sendmail.mc file
– Definitions
• Configured via FEATURE and DEFINE statements in .mc file
• Define variables
– Define()dnl
• Define macros to perform functions
– Feature()dnl
• Define classes (sets of names)
– Rules
• parse address, and re-write it for transport.
• Use macros, classes, and variable definitions during re-write.
• Apply rules to reject spam and other messages.
– Mailers
• Define the mailers that are available for mail delivery on this
system.

31. Email
• Variables That Control Sendmail Configuration
– Most of the Build options for Sendmail are implemented as a series
of macro definitions, and/or variables the administrator can set.
• There are tens (if not hundreds) of variables that might be used to
customize Sendmail.
• The following is a partial list of variables that may be set via the
sendmail.cf configuration file, or via the siteconfig file.
– confMAILER_NAME: Sender name used for internally generated messages.
– confDOMAIN_NAME: Should only be defined if your system cannot determine your local
domain name.
– confCF_VERSION: If defined, this is appended to the configuration version name.
– confCW_FILE: Name of file containing host names this system accepts mail for.
– confCT_FILE: Name of file containing the list of trusted users.
– confCR_FILE: Name of file containing the list of hosts allowed to relay.
– confTRUSTED_USERS: Names of users to add to the list of trusted users. This list
always includes root, uucp, and daemon.
– confTRUSTED_USER: Trusted user for file ownership and starting the daemon.
– confSMTP_MAILER: Mailer name used when SMTP connectivity is required.

32. Email
• Variables That Control Sendmail Configuration
– confSEVEN_BIT_INPUT: Force input to seven bits.
– confEIGHT_BIT_HANDLING: Enable 8-bit data handling.
– confMAX_MESSAGE_SIZE: Maximum size of messages accepted (in bytes).
– confMIME_FORMAT_ERRORS: Send error messages as MIME-encapsulated messages
per RFC 1344.
– confFORWARD_PATH: Colon-separated list of places to search for .forward files.
– confLOG_LEVEL: Log level.
– confPRIVACY_FLAGS: Privacy flags.
– confTIME_ZONE: Zone info. Can be USE_SYSTEM to use the system’s idea, USE_TZ to
use the user’s TZ environment variable, or something else to force that value.
– confUNSAFE_GROUP_WRITES: If set, group-writable, :include: and .forward files are
considered “unsafe.” That is, programs and files cannot be directly referenced from
such files. World-writable files are always considered unsafe.
– confDONT_BLAME_SENDMAIL: Override Sendmail’s file safety checks. This will
definitely compromise system security and should not be used unless absolutely
necessary.
– confAUTH_MECHANISMS: List of authentication mechanisms for AUTH (separated by
spaces). The advertised list of authentication mechanisms will be the intersection of
this list and the list of available mechanisms as determined by the CYRUS SASL library.

33. Email
• Sendmail.mc file variables
– use_cw_file: Reads the /etc/mail/sendmail.cw file to get a list of hosts the
server will accept messages for.
– use_ct_file: Reads the /etc/mail/trusted-users file to get the names of users
that will be “trusted.”
– stickyhost: This feature is sometimes used with LOCAL_RELAY, although it
can be used for a different effect with MAIL_HUB.
» When used with without MAIL_HUB, e-mail sent to user@local.host is
marked as “sticky” and is not forwarded to LOCAL_RELAY. With
MAIL_HUB, mail addressed to user@local.host is forwarded to the mail
hub, with the envelope address remaining user@local.host. Without
stickyhost, the envelope would be changed to user@mail_hub, in order to
protect against mailing loops.
– always_add_domain: Includes the local host domain even on locally
delivered mail.
– ldap_routing: Implements LDAP-based e-mail recipient routing according to
the Internet Draft draft-lachman-laser-ldap-mail-routing-01.
– Nullclient: A special case. Creates a configuration file containing nothing
but support for forwarding all mail to a central hub via a local SMTP-based
network.
– promiscuous_relay: By default, the Sendmail configuration files do not
permit mail relaying (that is, accepting mail from outside your local host
and sending it to a host other than your local hosts).

34. Email
• Sendmail.mc file variables
– relay_entire_domain: By default, only hosts listed as RELAY in the access
db will be allowed to relay.
– relay_hosts_only: By default, names listed as RELAY in the access db are
domain names, not host names.
– relay_mail_from: Allows relaying if the mail sender is listed as RELAY in the
access map.
– relay_local_from: Allows relaying if the domain portion of the mail sender is
a local host.
– accept_unqualified_senders: Normally, MAIL FROM: commands in the
SMTP session will be refused if the connection is a network connection and
the sender address does not include a domain name.
– accept_unresolvable_domains: Normally, MAIL FROM: commands in the
SMTP session will be refused if the host part of the argument to MAIL
FROM: cannot be located in the host name service (e.g., an A or MX record
in DNS).
– access_db: Turns on the access database feature.
– blacklist_recipients: Turns on the ability to block incoming mail for certain
recipient user names, host names, or addresses.
– delay_checks: The rule sets check_mail and check_relay will not be called
when, respectively, a client connects or issues a MAIL command.
– dnsbl: Turns on rejection of hosts found in an DNS-based rejection list.

35. Email
• Summary of the sendmail configuration file
– /etc/sendmail.cf is built from the sendmail.mc file
– /etc/mail/sendmail.cf - controls nearly everything:
• sets global variables and options
• defines macros and classes (sets of names)
• describes syntax of message headers
• defines Delivery Agents (mailers) that may be used
• defines rule sets
– based on a “production system” programming language
– Line at a time syntax
– Read only at startup

36. Email
• Creating a sendmail.cf
– Used to be a guru function.
• Hand editing of an existing sendmail.cf file
– Complicated
– Easy to mess up
– Have to understand sendmail language
– Better to create a sendmail.mc file, let the system build .cf file for
you
• Easier to port changes
• Less knowledge of language required – just need to
understand macros

37. Email
• Rewrite rules read “tokens” and make decisions based on contents of
the token stream. The left hand side of rewriting rules contains a
pattern. Normal words are simply matched directly. Metasyntax is
introduced using a dollar sign. The metasymbols are:
$* Match zero or more tokens
$+ Match one or more tokens
$- Match exactly one token
$=x Match any phrase in class x
$~x Match any word not in class x

38. Email
– Example:
• curt@cse.nd.edu (user@host.domain) could become 7 tokens:
curt @ cse . nd . edu
$1 $2 $3 $4 $5 $6 $7
$* $1=curt@cse.nd.edu
$+ $1=curt@cse.nd.edu
$+ @ $+ $1=curt $2=cse.nd.edu
$- @ $+ $1=curt $2=cse.nd.edu
$+ @ $- . $D $1=curt $2=cse
$+ . $+ . $=$T $1=curt@cse $2=nd $3=edu

39. Email
• Sendmail Operators
– When the left hand side of a rewriting rule matches,
the input is deleted and replaced by the right hand side.
Tokens are copied directly from the RHS unless they
begin with a dollar sign. Metasymbols are:
$n Substitute indefinite token n from LHS
$[name$] Canonicalize name
$(map key $@arguments $:default $)
Generalized keyed mapping function
$>n "Call" ruleset n
$#mailer Resolve to mailer
$@host Specify host
$:user Specify user
– The $n syntax substitutes the corresponding value
from a $+, $-, $*, $=, or $~ match on the LHS

40. Email
HSubject: $>CheckSubject
D{MPat}Important Message From
D{MMsg}This message may contain the Melissa virus.
D{HPat}Homeworkers Needed
D{HMsg}Go away spammer
SCheckSubject
R${MPat} $* $#error $: 553 ${MMsg}
RRe: ${MPat} $* $#error $: 553 ${MMsg}
R${HPat} $* $#error $: 553 ${HMsg}
RRe: ${HPat} $* $#error $: 553 ${HMsg}

41. Email
LOCAL_RULESETS
SLocal_check_mail
R$* $:$1 $| $>Local_check_numb $1
R$* $| $#$* $#$2
R$* $| $* $@ $>Local_check_bull $1
R$* $| $#$* $#$2
#
SLocal_check_numb
R$* $: $>Parse0 $>3 $1
R$+ < @ $+. > $* $: $(allnumbers $1 $)
R@MATCH $#error $: 553 Header Error
#
SLocal_check_bull
R$* $: $>Parse0 $>3 $1
R$+ < @ $+. > $* $: $(SpamFriend $1 $)
R@MATCH $#error $: 550 We no longer accept spam email from you
#
# now call Basic_check_mail to continue processing
#
R$* $| $* $@ $>"Basic_check_mail" $1

42. Email
– Reading/understanding rewrite rules requires a lot of practice!
– Sendmail has a debug mode that allows the administrator to see
how the rule set works.
– User can use mail -v to see what happens to mail they send.
• Recent additions
– New rules allow user authentication.
• Authentication
– Block relaying as a general rule
– Enable authentication
» User authenticates to server.
» If user is valid, allow relaying.
» Can also use SSL encryption as part of this process.

43. Email
• Recent additions
– As of sendmail 8.8 there are also new macro’s and rewrite rules
that allow administrators to build in rules to block spam.
• Spammers use several tricks to get their mail sent with bogus
addresses:
– Connect to someone else’s SMTP service and
send a flood of stuff (Relaying).
– Guerrilla mailers that munge the envelope and
headers to hide the real point of origin.
– Mailers that use bogus domains or user names in
the mail from line.

44. Email
• Statistics
– A small ISP reported that in 80 days they received 257,000
pieces of email at their SMTP server.
• Of that, 2,500 messages were real mail (<1% of total).
• Another 2,500 messages were automated reports (<1% of total).
• The rest was SPAM! (>98% of total).
– Yahoo (purportedly) delivers 1 BILLION pieces of spam
per day.
• This is after their filters remove 4 out of 5 spam messages
that they receive at their SMTP servers!
– If you multiply the number of Internet users in the USA by
the average number of spam messages that they receive
per day, and use minimum wage as a cost factor, spam
costs the US $622 billion a year!

45. Email
• Relaying
– A “hack” typically used to deliver spam
• I create message
• I send message to user@somewhere_else@your_server
• Your server accepts message and delivers it for me.
• You take the heat for the spam.
• If I forge the headers correctly, you cannot trace it to me.
– Message MIGHT be a mobile user
• Mail from a staff member on the road
• Mail from a staff member’s “home” account
• Need to control relaying
– Detecting Relaying - is incoming message destined for a user on this
host?
• If so, accept.
• If not, this is a relay attempt.

46. Email
• The anti-spam rules can check:
– Valid sender hostname - look up sending host in DNS.
• If it does not exist, do not accept mail.
– Access databases - Local and global lists may be
checked:
• RBL - network services which tracks spammers, relay
sites, and dialup ISP’s.
– Works like DNS – look up host at the RBL service,
if an answer comes back from RBL server, do not
accept this message.

47. Email
• The anti-spam rules can check:
• access.db - a local database of sites/users you will not
accept mail from.
– Create a text file with a key, and an action:
» Key is one of: a user name, a domain name, or a
user@domain
» Action is one of: OK, REJECT, or RELAY

48. Email
• Access Database
nd.edu RELAY
cselab.nd.edu RELAY
cse.nd.edu RELAY
austin.ibm.com RELAY
129.74 OK
nobody@ REJECT
largetvs@ REJECT
customersupportrep@ REJECT
bttb.net REJECT
free-virtualweb.org REJECT
thefreevirtual.org REJECT
friend.of.you@ REJECT

49. Email
– anti-spam rules:
• Rulesets can return fatal, or transient error messages
– Fatal error - sender gets a bounce message.
– transient error - ties up resources, no bounce message.
• Check Subject line and other headers
– Useful for virus rejects and anti-spam.

50. Email
• When building the sendmail binary, there are several
options that need to be considered:
– By default, sendmail will use the OS’s simple database facilities.
• Often, this is not a good choice. You may need to install a more
robust database package for use with sendmail.
– You may need to compile name service or directory service
(LDAP, NIS, …) information into your sendmail.
– Generally want to put localisms in the devtools/Site directory in a
file called siteconfig.m4
• Use the Build utilities to include the localisms into the sendmail
binary.

51. Email
• Mail Logfiles
– An important part of the email system is the ability to
prove where the mail came from, and how it was
handled in transit.
– Mail logging is configured in the sendmail.cf file, and
via the syslog facility.
• Mail log files are very useful in case you need to trace
the operation of the mail system.
– You can chain together the unique message
ID’s and prove origination/routing of a message.
– Should be kept locked up (otherwise users can
see who others are mailing).
• Recent versions of sendmail have improved the
sender authentication.

52. Email
• Security
– Sendmail has been blamed for a lot of security problems.
– New sendmail (8.9 and later) has a lot better security
(and includes a way to override security by setting the
“DontBlameSendmail” variable).
– One well-known security “hole” is the “telnet host 25”
trick.
• Can send bogus mail and make it show up as though
someone else sent it.
• in.identd process can catch this in progress, and
provide sendmail with information about the real
sender.
– Mail User agents might not show this information
to the user by default.

53. Email
• Mail Security Overview
– The administrator should take every opportunity to try to
convince users to employ secure protocols for mail
delivery.
• POP/IMAP connection sends their log-in and password across
the network in plain-text form.
• To secure such connections, the administrator should install an
SSL-encrypted POP and IMAP service, and teach users how to
access this service.
• Once users have been given time to convert to secure services,
plain-text services should be disabled.

54. Email
• Mail Security Overview
• Securing Mail User Agents
– Mail user agents typically do not provide much to ensure
the security of the mail system.
• By default, MUAs do everything in plain-text mode allowing
prying eyes to snoop the network and to read e-mail messages.
• This implies that the user should use some form of encryption
tool if she wants to ensure the privacy of messages.
• Many MUAs contain options that allow the user to
make use of encrypted mail delivery services.

55. Email
• Mail Security Overview
• Securing Mail Servers
– Hosts that run an MTA daemon may be susceptible to
another security problem.
• An improperly configured mail server will allow anyone to connect
to it, and send mail using the mail server as the “From:” address.
Such servers are referred to as open (mail) relays.
• People that generate and send spam mail messages often make
use of open relays. The spammer finds a host that allows open
relaying, creates the message to be sent, and uses the third-
party mail server to send the message.
• When people that received the spam start complaining, they
send mail to the owner of the improperly configured mail server.
• The owner of the mail server did not create the spam message,
nor can he track where it came from, but he will certainly get a lot
of fan mail from people that received the spam message!

56. Email
• Mail Security Overview
– Open relaying has been disabled in recent versions of
the Sendmail MTA software, but the administrator has
the ability to reenable this mode of operation.
• Reenabling open relaying is strongly discouraged! Instead,
look into building a version of Sendmail that authenticates
users, and allows authorized users to relay mail via the
mail server. This combats the spam problem in two ways.
– First, the authentication step logs the name of the user that
authenticated. This allows the administrator to track who
generated any spam mail that does get relayed through the
site.
– The authentication step also combats spam by requiring the
user to authenticate in order to use the MTA to relay
messages. This prevents users that do not have a valid log-
in/password on the mail server from accessing the mail
system.

57. Email
• Playing Post Office
– In most organizations, users have a personal computer on their
desk where they read their mail.
• Some users will have even smaller systems (such as a Palm,
Blackberry, or cellular phone) that are too small or too
infrequently connected to the network to act as a mail server.
– Rather than making all of these systems full-fledged mail
servers, a separate local delivery system is used.
– Each user’s PC makes requests to retrieve mail on demand
in a manner similar to a person checking a post office box.
• There are two methods for providing post office services.

58. Email
• POP
– The Post Office Protocol (POP) is a simple mail retrieval protocol.
• The most recent version of the protocol, version 3, is detailed in
RFC1939.
• A POP mail client authenticates itself as a particular user to the POP
server, and can list, retrieve, and delete messages from that user’s
mailbox.
• POP provides two internal authentication schemes, plain-text and APOP.
– APOP uses a time stamp, and a shared secret to produce an MD5
digest that is used to authenticate the user.
– Although APOP helps to secure the user’s password, the user name
and all of the user’s e-mail still pass along the network in the clear.
– A more secure method is the use the POP protocol over a secure
socket layer (SSL) connection.
– POP is usually not run as a persistent daemon, but is started on
demand via the inetd or xinetd daemon.
» As with other inetd services, wrapping the POP server using tcpd
or using the built-in access control features of xinetd is strongly
recommended both for connection logging and access control.

59. Email
• POP
– The Post Office Protocol (POP) is a simple mail retrieval protocol.
• The most recent version of the protocol, version 3, detailed in
RFC1939.
• A POP mail client authenticates itself as a user to the POP
server, and can list, retrieve, and delete messages from that
user’s mailbox.
• POP allows two internal authentication schemes, plain-text and
APOP.
– APOP uses a time stamp, and a shared secret to produce an
MD5 digest that is used to authenticate the user.
– Although APOP helps to secure the user’s password, the
user name and all of the user’s e-mail still pass along the
network in the clear.

60. Email
• POP
– A more secure method is the use the POP protocol
over a secure socket layer (SSL) connection.
– POP is usually not run as a persistent daemon, but
is started on demand via the inetd or xinetd
daemon.
» As with other inetd services, wrapping the POP
server using tcpd or using the built-in access control
features of xinetd is strongly recommended both for
connection logging and access control.

61. Email
• IMAP
– The downside to POP is that the user’s e-mail is
removed from the server and copied onto the user’s
system.
• The Internet Message Access Protocol (IMAP) offers a solution
by providing a file-server-like facility tailored to handling e-mail.
– IMAP clients authenticate as a particular user to an IMAP
server.
– IMAP clients can then obtain lists of messages and read
messages, as well as manage e-mail folders.

62. Email
• IMAP
– All of the user’s e-mail can remain on the server, and be
sorted and stored in folders managed via the IMAP client.
» On a server with adequate disk space and backups, IMAP
can provide a more flexible and reliable system than POP.
» IMAP is particularly well suited for users who access their
e-mail from more than one client.
– IMAP is a completely plain-text protocol.
» To provide security, IMAP can be run over an SSL
connection.
» Like POP, IMAP is typically started via inetd or xinetd, and
should be protected using a TCP wrapper .

63. Email
• IMAP
– There are several drawbacks to using IMAP.
» First, IMAP makes much heavier use of the server than
does POP, both in terms of disk space and I/O.
» Second, there are fewer IMAP clients available.
» Finally, accessing mail folders via IMAP can be slower
than accessing local mail folders on a given e-mail client.

64. Email
• Mail User Agents (Mail Clients)
– There are numerous MUA applications available for
various operating system environments. Each offers
different options, configuration methods/files, and user
interfaces.
– Choosing an MUA
• A wise administrator will find two or three (at most) MUAs and
make them available to local users.
• These will be the “supported” MUAs for the site. If users want to
use an MUA that is not on the approved list, they will do so at
their own risk.
• The administrator should consider (at least) the following factors
while choosing an MUA for the site.

65. Email
• Mail User Agents (Mail Clients)
• Security
– On personal computers, content-based attacks (in the form of
viruses and other malicious software) is a security issue.
– A mail client can help or hinder efforts to defend against these
problems.
– Like other Internet software mail clients, MUAs need to be
robust in the face of malformed input data.
– Mail clients that have tightly integrated scripting functions
have been used to launch attacks from infected personal
computers.
» Mail clients should be configurable to prevent the
execution of embedded scripts, viewing of HTML
attachments, and execution of attachments found in
incoming messages.
• WARNING: Microsoft’s Outlook and Outlook Express have a long history
of poor security and have been the vectors of infection for a large number
of viruses and other malware. The tight integration of scripting in Outlook
is frequently exploited to reach beyond the individual PC and spread the
infection to other systems.

66. Email
• Mail User Agents (Mail Clients)
• Availability
» Users with a wide range of skills will use mail clients on a
wide range of platforms.
» Mail clients that are available on multiple platforms and
that offer the same user interface can save on user training
and support effort, and allow consistent configuration
across the organization.
• Support for Communication Standards
» A good mail client supports current standards for
communication and content.
» Clients that support the secure forms of POP, IMAP, and
SMTP are excellent choices for mobile users and
environments with wireless networks.
» Clients that can properly handle MIME attachments, to
facilitate document exchange, are a requirement in many
environments.

67. Email
• Web-based Mail
– An alternative mail client that offers another solution for
mobile users and users who employ multiple hosts is
web-based mail.
• A web-based mail client is a suite of CGI programs, or
an application server program, that act as a mail client
using a web browser as the user interface.
• Web-based mail can be used from any client platform
that has a web browser.
• If the web server offers encrypted connections, web-
based mail can make use of the encrypted connection
to protect the user ID, password, and message
content.

68. Email
• Web-based Mail
• Setting up a web-based mail client requires obtaining
and installing the needed CGI programs and
supporting programs and adding them to the web
server configuration.
– For example, SquirrelMail requires Apache, PHP, and an
IMAP server, as well as the SquirrelMail software.
– To provide a secure connection, a web mail client will also
require configuring the web server to use SSL.

69. Email
• Miscellaneous Mail Tools
– System administrators of mail servers should be aware of a few
ancillary e-mail tools that may be of help in their environment.
• procmail: The procmail filter is the default delivery agent on
some UNIX variants, such as Red Hat Linux. It reads a rule set
that can filter mail messages in a variety of ways. procmail is
often used to pass e-mail through other filtering programs.
• spamassassin: One of the best tools for identifying those
annoying and unwanted commercial e-mails or SPAM.
spamassissin uses several methods to attempt to identify a
message as SPAM. It can be run several ways, including via
procmail.
• fetchmail: fetchmail is a batch-oriented, command line POP and
IMAP client. It is useful for situations in which noninteractive
access to a mail server is needed.

70. Summary
• Keeping e-mail flowing is a required task for most
system administrators.
• Choosing a good mail transport agent and properly
configuring it is a good place to start, but the
administrator also needs to think through
– the site’s e-mail model,
– user agents, and
– hardware required to provide this critical service.
• Users will benefit from a well-chosen combination
of e-mail client and post office service daemon.