IY5511 – Network Security

M.Sc. in Information Security

Royal Holloway, University of London

1
IY5511 – Network Security

Lecture 7
E-mail Security

2
 Objectives of Lecture

• Understand how e-mail systems operate over

networks.
• Classify the threats to the security of e-mail.

• Study two schemes that can be used to add security to

e-mail systems.
– S/MIME (Secure Multipurpose Internet Email Extensions).
– PGP (Pretty Good Privacy).
• Examine what other security measures are needed to
ensure security for e-mail systems.

• Bring together diverse elements to understand the

security of a key application.

3
CINS/F1-01
Contents

7.1 Why study e-mail security?

7.2 E-mail – what it is and how it works.
7.3 E-mail security threats
7.4 Secure e-mail standards and products - PGP
and S/MIME.
7.5 E-mail security beyond PGP and S/MIME.

4
7.1 Why Study E-mail Security?

• E-mail is one of the most widely used network-reliant

applications.

• Yet basic e-mail offers little security.

– Contrary to public perception?

• Good technical solutions are available, but not widely

used.
– If we understand why this is so, we might understand
something about why security is ‘hard’.

• E-mail security makes a good case study for IY5511.

– A single, well-defined network application whose security we
can evaluate.

5
7.2 What Email Is and How It Works

• What is an e-mail?
– IETF Standards define the message format.
• RFC 822.
• MIME (Multipurpose Internet Email Extensions).
• How are e-mails transported, accessed and
stored?
– MUA (Mail User Agents).
– MTA (Mail Transfer Agents).
– More IETF Standards.
• SMTP (Simple Mail Transfer Protocol).
• POP3 (Post Office Protocol v3).
• IMAP (Internet Message Access Protocol).
6
RFC 822

• An e-mail is a message made up of a string of

ASCII characters in a format specified by
RFC 822 (dating from 1982).
– Latest version is RFC 2822 (2001).
• Two parts, separated by blank line:
– The header: sender, recipient, date, subject,
delivery path,…
– The body: containing the actual message content.
• Use of ASCII causes problems for non-ASCII
message bodies, e.g. attachments – more
later.
7
An Example RFC 822 Message

From: Allan.Tomlinson@rhul.ac.uk
To: Kenny.Paterson@rhul.ac.uk
Cc: kennypaterson@hotmail.com
Subject: RFC 822 example
Date: Fri, 18 Nov 2005 13:58:49

This is just a test message to

illustrate RFC 822. It’s not very long
and it’s not very exciting. But you get
the point.

8
MIME
• MIME (Multipurpose Internet Mail Extensions) specifies
a standard format for encapsulating multiple pieces of
data into a single e-mail message.

• Extends RFC 822 to allow e-mail to carry non-textual

content, non-ASCII character sets, long messages.

• Uses extra header fields in RFC 822 e-mails to specify

form and content of extensions.

• Supports various content types, but e-mail still ASCII-

coded for compatibility with RFC 822.

• Specified in IETF standards RFC 2045-2049.

9
MIME headers
MIME specifies 5 new RFC 822 header fields:
3. MIME-Version (must be 1.0)
4. Content-Type
5. Content-Transfer-Encoding
6. Content-ID - optional
7. Content-Description - optional
N.B. An additional optional header field,
Content-Disposition, is also widely used to
handle attachments and their presentation.
This MIME field is specified in RFC 2183.

10
MIME Content-Type
• Seven major content types with 15 sub-types.

• Multipart content type has 4 subtypes.

• Most important is Multipart/mixed,

indicating that the body contains multiple parts.

• Each part can be a separate MIME message –

hence nesting of MIME messages to any level.

• Parts separated by a boundary string defined in

Content-Type field.
11
Content-Transfer-Encoding

• RFC 822 only allows ASCII characters.

• MIME messages transport arbitrary data.

• The Content-Transfer-Encoding field

indicates how data was encoded from raw data
to ASCII.
• base64 is a common encoding:
– 24 data bits (3 bytes) at a time encoded to 4 ASCII
characters.
– Results in data expansion.

12
An Example MIME Message
From: Allan.Tomlinson@rhul.ac.uk
To: Kenny.Paterson@rhul.ac.uk
Subject: That document
Date: Wed, 16 Nov 2005 19:55:47 -0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="next part"
--next part
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Kenny, here’s that document I said I’d send. Regards, Allan

--next part
Content-Type: application/x-zip-compressed; name=“report.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename= “report.zip"

rfvbnj756tbGHUSISyuhssia9982372SHHS3717277vsgGJ77JS77HFyt6GS8
--next part--

13
How Are E-mails Transported?

LAN
LAN
MTA
Internet

MUA MUA
Sender Recipient

MTA

• MUA= Mail User Agent, aka Mail Client.

• MTA=Mail Transport Agent, aka Mail Server.
14
Composition and Delivery – 1

• MUA = Mail client is a program running on Sender’s

machine, e.g. Microsoft Outlook or Netscape
Messenger.
• Sender supplies To: and Subject: fields and
message body.
• MUA translates into RFC 822 message and connects
across LAN to MTA = Mail server.

• MUA instructs MTA using a protocol called Simple Mail

Transfer Protocol (SMTP), or a proprietary alternative,
and sends RFC 822 message.

15
Composition and Delivery – 2

• Sender’s MTA uses DNS (Domain Name Service) to

find IP address of recipient’s MTA (could be local)
based on To: field.
• Sender’s MTA opens connection to Recipient’s MTA
and uses SMTP to instruct remote MTA and transfer
RFC 822 message.
– Transfer is often across the public Internet.
• Intermediate MTAs may be involved.
• Recipient’s MTA may deliver to their MUA or may
store message locally for later retrieval across LAN.

16
Simple Mail Transfer Protocol

• Basic SMTP is defined in RFC 2821, widely used for

MUA-MTA and MTA-MTA conversations.
• SMTP uses TCP on port 25 for connections, so
SMTP traffic carried over LAN and Internet and is
(largely) unprotected.
• ‘Skilled’ user can talk SMTP directly over a telnet
connection to remote MTA, supplying From: field of
choice.
• So forging e-mail is nearly trivial (though mail
headers usually give away source IP address).

17
Where’s The E-mail?

• UNIX systems often transfer e-mail from MTA

to files in local client file system.
– Use elm, pine, xmail to read e-mail on client
machine.
– UNIX username and password controls access to
client mailbox.
– Thus security of mail system partly relies on user
account security.

18
Where’s The E-mail?
• Can also store e-mail on mail server rather than on
client machine.
• Two common protocols for mail client-mail server
interaction:
– POP3 (RFC 1939, v3).
– IMAP (RFC 3501, v4rev1).

• Username and (hashed) password required before

mail can be accessed.
– Often sent over network in clear.
– As used at RHUL: Microsoft Outlook mail client,
and Microsoft Exchange mail server.
• Secure extensions to POP and IMAP also exist.
19
Web-based Access
• Useful for users with web browser but no mail
client, e.g. user on the road.
• Username/password combination to control
access.
• Now entire client-server interaction over HTTP
instead of POP/IMAP.
– What happens to passwords in cybercafe?
Keyboard sniffers?
– Does history on browser reveal mail messages read
and sent?
• Possibly protected using SSL.
– E.g. RHUL’s webmail service.
20
7.3 E-mail Security Threats

We will distinguish two kinds of threats to the

security of e-mail:

Threats to the security of e-mail itself

Threats to an organisation that are enabled

by the use of e-mail.

Other classifications are possible!

Not an exhaustive list of threats!
21
Threats to E-mail

• Loss of confidentiality.
– E-mail is sent in clear over open networks.
– E-mail stored on potentially insecure clients and
mail servers.
– Ensuring confidentiality may be important for e-mail
sent within an organisation.

• Loss of integrity.
– No integrity protection on e-mails;
body can be altered in transit or on mail server.
22
Threats to E-mail

• Lack of data origin authentication.

– Is this e-mail really from the person named in the

From: field?
• How many John.Smith’s are there?
• Recall SMTP directly over telnet allows forgery of all
e-mail fields!
– E-mail could also be altered in transit.
– Even if the From: field looks fine, who was
logged in as John.Smith when the e-mail was
composed?
• Sharing of e-mail passwords common.

23
Threats to E-mail

• Lack of non-repudiation.
– Can I rely on, and act on, the content?
– If so, can the sender later deny having sent it?
Who is liable if I have acted?
– Example of stock-trading via e-mail.

• Lack of notification of receipt.

– Has the intended recipient received my e-mail
and acted on it?
– A message locally marked as ‘sent’ may not have
been delivered.
24
Threats enabled by E-mail

• Disclosure of sensitive information.

– It’s easier to distribute information by e-mail

than it is by paper and snail mail.
– Disclosure may be deliberate (and malicious)
or unintentional.
– Disclosure may be internal or external
(e-mail crosses LANs as well as the Internet).
– Disclosure may be of personal, inappropriate,
commercially sensitive, or proprietary information.
– Can lead to loss of reputation and possibly to
dismissal of staff.

25
Threats enabled by E-mail

• Exposure of systems to malicious code.

– Today, e-mail is one of the main vectors by which

malicious code is spread.
– E-mail virus: self-replicating code embedded in e-
mail, exploiting features/vulnerabilities of e-mail
clients.
• Visual basic script;
• Javascript in html formatted e-mail;
• .exe attachments.
– Often requires user interaction to propagate an
e-mail virus (but not always) .
– Virus outbreak can result in Denial of Service.
26
Threats enabled by E-mail

• Exposure of systems to Denial of Service

(DoS) attacks.
– E-mail server attached to Internet, so vulnerable to
DoS attacks.
– More relevant with increasing dependence on e-mail
as a communications tool.
– Denial of e-mail service as a secondary impact.
• A virulent worm using large percentage of network capacity
to spread will prevent efficient use of e-mail.

27
Threats enabled by E-mail

• Exposure of individuals to denial of service

attacks.
– Mail bombing and excessive spam.
– Individuals get so swamped by incoming e-mail that
they stop reading it and switch to other
communication methods.

28
Threats enabled by E-mail
• Spamming.
– Bulk distribution of unsolicited e-mail.
– 50% and more of all e-mail traffic is now spam, more than 10 billion e-
mails per day.
– Spammer can buy CD of e-mail addresses for a few dollars.
• See, for example, http://www.emailsondemand.com/
– Spammers used to target mail servers with “open relay” feature
enabled.
• A properly secured SMTP mail relay should not accept and forward
arbitrary e-mails from non-local IP addresses to non-local mailboxes.
• Blacklisting sites such as www.ordb.org used to provide lists of such
servers to be blacklisted.
• Spammers were then forced to evolve their attack methods.
– Today, home PCs connected to Internet via fast broadband
connections are the spammer’s platform of choice.
• Hacker takes over PCs via remote exploits to create “Zombie PCs”.
• Spammer can then rent a network of Zombies – a botnet – from hacker.
• Owner of PC pays for bandwidth, not spammer!
29
Threats enabled by E-mail
• Anti-spam legislation now on the statute books in many
countries.
– Federal CAN-SPAM act in force in US since 1/1/2004.
• Does not outlaw spamming, but controls use.
• First conviction in September 2004, Nicholas Tombros, spamming
+ war-driving.
– See http://www.spamlaws.com/ for details of laws in US and
elsewhere.
– Effectiveness of the US CAN-SPAM act and similar legislation
still in question.
• We still get large amounts of spam; investigation is time-
consuming, costly and needs international co-operation.

30
Threats enabled by E-mail

31
Threats enabled by E-mail

• Unauthorized access to systems.

– Mail servers can have many security

vulnerabilities.
• At OS and Application levels.
– They are also attached to external networks.
• Perfect target for hacker.
– Lead to your mail server being used as attack
platform on other systems.
• Your own and other peoples’.
– Consequent loss of reputation and potential
damages claim.

32
Threats enabled by E-mail

• Any more threats?

33
7.4 Secure E-mail Standards and
Products

• We will focus on S/MIME and PGP.

– Other now defunct standards: PEM (privacy
enhanced mail), X.400.
– Parts of these persist: PEM introduced base64
encoding, X.400 led to X.509 certificate standards.

• Lots of commercial products. Examples:

– Hushmail (www.hushmail.com),
– Identity-based secure e-mail
(www.voltagesecurity.com),…

34
S/MIME

• Originated from RSA Data Security Inc. in 1995.

• Further development by IETF S/MIME working group
at: www.ietf.org/html.charters/smime-charter.html.
• Version 3 specified in RFCs 2630-2634.
• Version 3.1 updates in RFCs 3370, 3850-3852.
• Allows flexible client-client security through
encryption and digital signatures.
• Widely supported, e.g. in Microsoft Outlook,
Netscape Messenger, Lotus Notes.

35
S/MIME Message Formats

• Adds security features by extending MIME.

• Adds 5 new content type/subtype
combinations, including:
2. application/pkcs7-mime;smime-type=enveloped-data

3. application/pkcs7-mime;smime-type=signed-data

4. multipart/signed

– Remaining types for key management messages.

36
S/MIME Processing

• S/MIME processing can be applied to

any MIME entity:

– One part of a MIME multipart message, perhaps one

that is itself of S/MIME Content-Type.

– Hence encryption and signature can be applied one

after another (and in either order).

– End result of S/MIME processing is always another

MIME entity, of S/MIME Content-Type.

37
S/MIME Processing – Sender

MIME CMS S/MIME

entity object entity
S/MIME Base64
processing encoding

• Initial S/MIME processing produces a CMS object.

– CMS = Cryptographic Message Syntax, based on:
• PKCS = Public Key Cryptography Standard, a set of specifications
developed by RSA.
• CMS defined in RFC 3852.
– CMS object includes information needed for processing by recipient
as well as the original content.
• But CMS objects are in binary format, hence need for further
base64 encoding to produce final result MIME object of
S/MIME content-type.
• Recipient performs steps in reverse. 38
 S/MIME enveloped-data

EnvelopedData S/MIME header

Session Recipient’s CMS object
Key K Public Key
RecipientInfo
S/MIME body:

E EncryptedKey Base64
encoding Base64
Asymmetric encoded CMS
EncryptedContent object
Info

MIME
entity E EncryptedContent

Symmetric

39
S/MIME enveloped-data

An example message (from RFC 3851):

Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition:attachment;filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GI
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jHd
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHh6

40
S/MIME enveloped-data

• S/MIME enveloped-data type provides a

data confidentiality service through encryption.

• S/MIME header contains original To:, From: and

Subject: fields,
– So protection not complete.

• Symmetric algorithm with session key for efficient bulk

encryption.
• Asymmetric encryption using recipient’s public key to
protect session key.

• Recipient reverses steps: obtain session key using

private key, then use this to decrypt EncryptedContent.
– Algorithms needed are specified in RecipientInfo and
EncryptedContentInfo blocks. 41
S/MIME signed-data

SignedData S/MIME header

CMS object
MIME Sender’s
entity Private Key SignerInfo
Signer’s Cert S/MIME body:
Sig and Hash alg ID
Base64
Hash Sign Signed Hash encoding Base64
encoded CMS
object
MIME entity

42
S/MIME signed-data

An example message (from RFC 3851):

Content-Type: application/pkcs7-mime;
smime-type=signed-data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition:attachment;filename=smime.p7m

567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB97
7n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHU
HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8

43
S/MIME signed-data

• S/MIME signed-data type gives data integrity, data

origin authenticity and non-repudiation services using
sender signatures.

• Multiple signers are supported.

– Prepare a SignerInfo block for each one.
• Recipient checks signature using:
– S/MIME entity embedded in PKCS object, and
– Public (verification) key of sender.
• Recipient without S/MIME capability cannot read the
original message (even if he doesn’t care about
signatures).
44
S/MIME Clear Signing

• Uses MIME multipart/signed content type.

– First part contains MIME entity to be signed.
– Second part contains
S/MIME application/pkcs7-signature entity,
created as for signed-data type.

• Recipients who have MIME but not S/MIME capability

can still read message contents.
• Recipients who have S/MIME capability use first part
as MIME object in S/MIME signature verification.

45
S/MIME Clear Signing

Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42
--boundary42
Content-Type: text/plain

This is a clear-signed message.

--boundary42
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition:attachment;filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tb6
--boundary42--

46
S/MIME Algorithms

• Symmetric encryption:
– DES, 3DES, AES.

• Public key encryption:

– RSA, ElGamal.

• Hashing:
– SHA-1, MD5.

• Signature:
– RSA, Digital Signature Standard (DSS).

47
PGP (Pretty Good Privacy)

• First released in 1991.

– Developed by Phil Zimmerman.
– Provoked export control and patent infringement
controversy.
• OpenPGP (RFC 2440, superseded by RFC 4880).
– Defined by IETF OpenPGP working group.
• Freeware: OpenPGP and variants:
– www.openpgp.org, www.gnupg.org
• Commercial:
– PGP Corporation at www.pgp.com.
• Available as plug-in for popular e-mail clients, can
also be used as stand-alone software.
48
PGP (Pretty Good Privacy)

• Functionality similar to S/MIME:

– Encryption for confidentiality.
– Signature for non-repudiation/authenticity.
• One level of processing only.
– So less flexible than S/MIME.
• Sign before encrypt.
– So signatures are on unencrypted data.
– Signatures can be detached and stored
separately.
• PGP-processed data is base64 encoded and
carried inside RFC822 message body.
49
PGP Algorithms

Broad range of algorithms supported:

• Symmetric encryption:
– DES, 3DES, AES and others.

• Public key encryption of session keys:

– RSA or ElGamal.

• Hashing:
– SHA-1, MD-5 and others.

• Signature:
– RSA, DSS, ECDSA and others.
50
PGP Key Rings

• PGP supports multiple public/private keys pairs

per sender/recipient.

• Keys stored locally in a PGP Key Ring

– Essentially a database of keys.

• Private keys stored in encrypted form

– Decryption key determined by user-entered
passphrase.
– So security once again depends on users
remembering passwords!
51
PGP and S/MIME Key Management

• PGP and S/MIME use

– Public keys for
• Encrypting session keys.
• Verifying signatures.

– Private keys for

• Decrypting session keys.
• Creating signatures.

• Where do these keys come from?

• On what basis can they be trusted?
52
S/MIME Key Management

• S/MIME uses public-key certificates and

certificate chains to validate public keys.

• Certificates comply with ISO/ITU-T X.509v3

public key certificate standard.

• Same standard as used to define certificates

in SSL/TLS and IPsec.

53
X.509 Certificate Format

An X.509 certificate is a data structure including the

following fields:
– Version number (1, 2, 3 or 4).
– Serial number of certificate.
– Issuer name.
– Validity period.
– Subject name – a “Distinguished Name”.
– Subject’s public key info: algorithms (eg RSA); parameters
(eg size); the public key itself.
– Extension fields.
– The Issuer’s signature on all the above fields.

54
Use of X.509 Certificates

• Issuer commonly called a Certification Authority (CA).

• Third party can check validity of Issuer’s signature in

certificate.

• Certificate can therefore vouch that subject is in

possession of the private key corresponding to the
public key in the certificate.

• But first need authentic copy of Issuer’s public key!

55
X.509 Certificate Chains

• Repeat the checking process on Issuer’s certificate,… until root of

trust is reached
– a certificate embedded in browser or e-mail client from a root
authority whose public key is implicitly trusted.
• Thus use a hierarchical chain of certificates.

Root
Authority’s
CA’s Cert Root public key
Authority’s
J.Smith’s CA’s Sig.
Cert Sig.
S/MIME J.Smith’s
message Sig.
56
X.509 and S/MIME

• Subject’s public key can be for either

verification or encryption.
– Usage specified in an X.509 extension field.
• X.509 Subject name must be a distinguished
name,
– e.g. “c=GB, o=company, ou=sales, cn=John Smith”.
– So X.509 does not directly support use of e-mail
addresses.
– Use another X.509 extension field “Alternative
Name” to include e-mail address in certificate.

57
S/MIME Key Management Issues

• Interpretation: End-user is asked: “Do you trust this

certificate?”
• Scale: How to manage large populations of users?
• Revocation: How to communicate to all users that a
certificate is no longer valid?
• Liability: How much liability (if any) does the Issuer
accept?
– Maybe OK if Issuer is your employer.

• Private key storage: End-user’s desktop most likely,

maybe password protected.
• Certificate issuance procedures (aka registration):
Is this really J. Smith? OK, which J. Smith?
58
PGP Key Management
• PGP adopts a completely different trust model:
the web of trust.
– No centralised authority like a root of trust in X.509.
– Individuals sign one another’s public keys, these “certificates”
are stored along with keys in key rings.
• Compute a trust level for each public key in key ring
– Formula used is based on:
• The number of signatures obtained for the public key, and
• User-assigned trust levels for the public keys
corresponding to those signatures.
• Users interpret trust level for themselves.

59
PGP Key Management Issues

• Original intention was that all e-mail users

would contribute to web of trust.
– Reality is that this web is sparsely populated.
– Later versions of PGP support X.509 certs.

• How should security-unaware users assign and

interpret trust levels?

• PGP fine for small groups combined with out-

of-band public key distribution (eg floppy).

60
7.5 E-mail Security:
Beyond PGP and S/MIME
• PGP and S/MIME counter the basic threats to
confidentiality, integrity and authenticity of
e-mail quite well.
– Assuming good key management and proper
implementation.

• They don’t protect against other threats:

– Virus, DoS, Disclosure, Unauthorized use,…

• They don’t protect against traffic analysis.

• Additional security measures are needed to build a

secure e-mail system.
61
Anti-virus and Content Filtering
• Supplement mail server (and/or clients) with
content/spam filtering software.
– Block e-mail with active content or specific attachment types.
– Reject or mark suspected spam e-mail.
– Scan incoming and outgoing e-mail for viruses and
inappropriate content.
– Add legal disclaimers.

• Server cannot apply content filter to encrypted e-mail

– Unless it has the relevant keys.

• Significant load on mail server, may annoy end users.

– Many third party service providers offer outsourcing option.

62
Anti-spam Protection

• Configure mail server to disable mail relay.

– Prevents server being used as an agent to forward
e-mail for third party spammers.

• Discard all e-mail from servers on blacklists.

• Control who can run an e-mail server in your

organisation.
– Through appropriate policy setting and enforcement.

63
Firewalls and Mail Servers

• Place mail server behind a firewall in network.

• Configure firewall to block all external traffic to/from
mail server except on port 25 (SMTP).
– Limits attack possibilities on mail server.
– But successful attack may give access to internal systems.
– Need additional security measures on server.
• Better to use a perimeter network.
– Fully isolate mail server from internal and external network
using firewall.
– Configure firewall to block all internal traffic to/from mail
server except on ports 25, 110 (POP3),143 (IMAP) and 53
(DNS).
– More details in lecture on firewalls.

64
Mail Server Hardening

Take additional measures on mail server:

• Harden OS:
– Remove unnecessary accounts, applications, and network
services.
– Apply latest OS vulnerability patches.

• Harden mail server application (e.g. sendmail,

Microsoft exchange):
– Use latest versions of software.
– Choose appropriate configuration settings.
• (e.g. limit attachment sizes, mail relay features and file
permissions).
– Keep up-to-date with vendor patches.

65
Mail Server Administration

• Log mail server data and review log files

regularly.
– Consider automated analysis.

• Keep up-to-date with latest patches and

vulnerability alerts.
• Consider allowing only console-based
administration or using SSH for remote
administration.
• Take appropriate backups of mail server and
user mail.
66
Client Side E-mail Security

Proper configuration and patching are essential:

• Disable automatic message preview.
• Disable active content processing
– macros, ActiveX, Java, Javascript,…
• Disable POP/IMAP “remember this password?”
dialogue boxes if possible.
• Consider strengthened POP and IMAP protocols.
• Be aware of extra risks of web-based access:
– Key stroke logging and user credential capture.
– Content over http may bypass content filters.
– Client e-mails may be left in browser history and temporary
files.

67
E-mail Policy and Training

• Develop and publicise an e-mail policy for

users.
– Rules of use, definitions of abuse of service,
ownership of e-mail, inspection, legal requirements
and responsibilities, retention policies,…
• Ensure users sign-up to policy before use.
• Raise awareness of security issues in
organisation through training.
• Enforce the policy!

68
Lecture Summary

• E-mail is routed across internal LANs and the public

Internet.
• E-mail is subject to many threats.
• E-mail also enables many threats.

• PGP and S/MIME can address part of the problem

through encryption and signature mechanisms.
• Addressing the remaining issues requires a careful
blend of computer security, network security and
security management countermeasures.

69
Some Resources
• M. Tracy et al., NIST Special Publication 800-45v2,
Guidelines on Electronic Mail Security, available from:
http://csrc.nist.gov/publications/nistpubs/index.html
• W. Stallings “Network Security Essentials”, Chapter 5:
more on PGP and S/MIME.
• http://www.spamlaws.com/: details on anti-spam
legislation.
• Open PGP: www.openpgp.org
• PGPv7 on ISG lab machines.
• S/MIME: www.ietf.org/html.charters/smime-charter.html
• All the RFCs are at www.ietf.org.
– http://www.apps.ietf.org/rfc/index.html
70