Email Protection

(BY ANUJ AGGARWAL AND SONALI SISODIA)

Introduction
This white paper provides an introduction to the subject of how to protect enterprises
that are connected to the Internet from junk email. The format of the paper is that an
authorisation issue is outlined and then the relevant. Mailer facilities are
described.
We will use the following scenario to help explain the authorisation issues. An
organisation called "Acme Inc" operates a message switch with an Internet host name
mailer.acme.com . A message switch is a software application that performs the transfer
and delivery of email messages.
Acme receives email from a number of organisations connected to its Internet Service
Provider - bigisp. These organisations include beta.com, pots.co.uk, and
spam.com (!). Note from the diagram above, that their messages are routed to Acme via
a remote mail host called gate.bigisp.net in the bigisp.net domain.
Acme both sends and receives messages via bigisp.net . However, we will focus on
the authorisation issues in the receiving mode. When the message switch at
gate .bigisp .net connects to mailer.acme.com to pass over messages, there are three
possible courses of action that the Acme message switch may take:
Refuse to accept messages from gate.bigisp.net (e.g. because the message
switch doesn’t know how to deliver them or they fail authorisation)
Deliver messages to the corporate network if they are addressed to local (i.e.
Acme) users
Relay messages addressed to non-local (i.e. non-Acme) users on to the appropriate
Internet domain
1 Althoughthe paper focuses on Internet mail, many of the issues and solutions apply equally well to
X.400 mail.
The initial authorisation decision to accept, deliver or relay messages arriving at the
Acme message switch is almost always based on the identity of the connecting
message switch. Nevertheless, authorisation decisions may actually be based on a
wider set of criteria including:
• Connecting message switch identity and
• Sending user identity
• Message Content
We will look at each of these criteria in turn starting with connecting message switch
identity. However, during the connecting message switch section we will
take time out to consider the issues surrounding the rejection of email.

Connecting Message Switch Identity Authorisation

In general, the world can be divided up into two trust groups, those we trust and those
we don’t. The relative size of these two groups in a message switch context will depend
upon the specific policy of the enterprise - which can range across the spectrum of
trusting almost every external message switch to trusting none. In practice an enterprise
will chose a default policy that is located towards one end of this spectrum or the other.
However, the usefulness of this approach depends upon the degree of confidence we
have that the true identity of the connecting message switch is known (i.e. that the
connecting message switch is not masquerading as a trusted message switch).
Ultimately, the only way to be certain that masquerade is not happening is to employ
complex authentication techniques that involve the message switches in the exchange
of digital certificates. Although this is possible within a secure network, it is not yet
possible to use such techniques at an enterprise mail gateway to the Internet (e.g. you
would not be able to respond to sales enquiries from potential new customers!).
Therefore, we will pass over certification techniques and focus on what one can do in
the Internet gateway situation. What steps can we take to check on message switch
identity?

Verifying Message Switch Host and Domain Identity

When the Acme message switch receives a request to accept an SMTP message, either
the IP address or host name of the connecting message switch is made available.
However, a host name can be forged (far more easily that an IP address). It is therefore
common practice for a message switch to be able to fully resolve (i.e. map) the
connecting message switch host name to an IP address via the Internet Domain Name
System service as an identity check.
The complete check involves the following steps:
1. If the connecting host presents as an IP address, the IP address is resolved to a
host/domain name mapping (e.g. 192.168.4.255 resolves to gate.bigisp.net)
2. The host/domain name found in step 1 is then reverse resolved into an IP address
(e.g. gate.bigisp.net resolves to 192.168.4.255)
Note that if the first of these two checks fails to resolve a host name (which can happen
if the sending mail host is not registered in the DNS), it is possible to decide to refuse
to accept messages from the connecting message switch immediately. Many sites
implement this; it is a common anti-spam technique. Whereas, if it does resolve to a
host/domain name, then an accept/reject decision could be made on the basis of
whether the name was known as "trustworthy" or not. However, at this point we should
consider performing the second check.
At first sight, the second check may seem to be pointless in that it mirrors the first. In
fact it provides a more complete check against misrepresentation. For example,
consider the following scenario. At some point, Acme will have ‘officially’ registered
the corporate domain name “acme.com” in the DNS in association with a set of
specified IP addresses via a registration authority. However, this does not prevent
spam.com from registering the reverse name mapping "mailhost.acme.com" to its mail
host IP address (a shortcoming of the DNS system!). Thus, if we perform only the first
check, it may appear that the connecting host is actually internal to the Acme corporate
domain. However, when we do the second check, we will discover that the IP address
found is spam.com - not one used in the Acme domain. A pretty good basis to reject
the mail!
One caution, these techniques only work for resolving host details of the currently
sending message switch (i.e. gate.bigisp.net in our diagram). However, the sending
message switch may not be the originating message switch if the message has been
relayed - e.g. the originating message switch could have been the one that passed the
message to dialup.bigisp.net in the diagram overleaf. Consequently, there is no
gain in applying these particular checks in this situation Hopefully,
dialup.bigisp.net performed them itself! This scenario shows how vital it is for
mail switches that relay messages to implement spam control.
It is important to point out that not everyone thinks that message switches should
automatically reject sites that fail the first (IP-> name mapping) check. Certainly,
many small companies, and even some large, may have not registered their message
switch host/domain name correctly - figures on how many Internet message switch
sites are not correctly set up for mail host DNS resolution are hard to estimate.
However, investigations on specific sites have shown that approximately 30% of
connection attempts fall into this category.

Mailer Verification Features

Mailer allows the default authorisation policy to be set to any of the above as
follows:
1. No check
2. Check IP name mapping
3. Check IP name mapping ; Check resolved name IP mapping
Mailer allows the choice of policy 2 or 3 as the default but also provides an
exception mechanism for trusted/untrusted connecting host IP addresses.
Mailer allows the administrator to customise the text of the SMTP protocol
rejection message. This message will usually be logged on the message switch that
initiated the connection. The text can explain the rejection reason and include
information about how the local mail administrator can be reached for further
discussion.
The Mailer can also record the details of the connections that are refused due
to the above policies. This information can be used by administrators to identify
specific hosts that need to be added to the ‘exceptions’ category on a daily, or other
period, basis. These added entries may be ‘aged’ so that at a future point they are
deleted and the authorisation policy will be invoked again on subsequent connections.

How to Reject Messages

Before we continue with the discussion of the authorisation of the connecting message
switch, it is useful to take time out to deal with the issue of exactly how a message
switch can reject mail and the implications of the choice on the message transfer
system. As we shall now make clear, this is very important to the originator (i.e.
author/sender) of the message.
Message transfer system design explicitly caters for the common types of failure and
rejection that may occur in the transmission of a message from its originator to its
recipient. One of the techniques used to indicate a problem is the use of a delivery
report (also called a delivery status notification) - an optional special message sent
back to the originator of the original message confirming the delivery or non-delivery
of their message to the recipient’s mailbox.
In message transfer, when gate.bigisp.net passes over a message to
mailer.acme.com, the Acme message switch accepts responsibility for delivering the
message and frees gate.bigisp.net from its responsibility for delivering the
message. It is important to the integrity of the whole email transfer process that this
responsibility is properly discharged only when the message is delivered to the
intended recipient(s).
Now it is also the case that if a message switch cannot discharge its responsibility by
passing on (relaying) or delivering a message that it has accepted, a non-delivery report
should be produced and sent back to the original sender. (Non-delivery can happen not
just for the reasons listed above, but also because of network failures that prevent the
message switch passing the message on to another message switch.) In summary, email
standards were designed so that reports can be used to verify successful or unsuccessful
message delivery.
However, since the standards were designed an important factor has been introduced
into the Internet world - unsolicited bulk email (UBE), otherwise known as spam!
Spam is a serious problem for message switches in that the act of rejecting thousands
of unwanted messages can involve the production of equivalent numbers of related
non-delivery reports that can tie up a message switch for many hours. This may mean
that legitimate users are denied the use of their messaging service. Therefore, in these
circumstances, it is important that a message switch be able to refuse to accept
messages and not have to generate the appropriate non-delivery reports.
There are two ways for a message switch to avoid producing delivery reports as a result
of message rejection:
Refuse to accept the message from the sending message switch (at the protocol
exchange level)
Accept the message and then discard it without producing a non-delivery report
The former is much the best policy in that it will cause the upstream message switch
(that currently has the message responsibility) to produce a non-delivery report for the
originator. In the latter case no non-delivery information gets back to the originator and
the discard has violated the mail transfer protocol. An issue to be aware of with the
latter approach is that legitimate email could be "lost" if an invalid decision is made to
block the message.
Having to undertake these kinds of rejection procedures is a regrettable situation and
against the co-operative ethos of message transfer. However, they are becoming a
necessary sanction against spammers.

Connecting Message Switch Identity Authorisation Continued

We have discussed the issues of verifying message switch identity as part of the
connecting message switch authorisation process. Let us now return to the issue of
choosing an authorisation policy. For example, the Acme may operate an email
authorisation policy based on one of the following rules:
1. Accept all mail except from those message switches listed in an ‘untrusted’ set
2. Reject all mail except from those message switches listed in a ‘trusted’ set
The Acme mail administrator will choose one of these two rules as the default
authorisation policy and categorise external message switches as trusted or untrusted -
unknown message switches being categorised as appropriate. Depending upon the
policy rule chosen, the appropriate un/trusted result set will be stored in the Acme
message switch configuration database so that rapid accept/reject decisions can be
made when a connection request is received.
What constitutes ‘trusted’? The issue can be addressed by taking a very selective view
of ‘trusted’ - e.g. message switches on Acme’s intranet. However, what about all the
Internet message switches out there? Rather than confining all to the untrusted set, it is
possible to seek advice concerning sites that are known for misbehavior. On the
Internet, a list of untrustworthy mail hosts is maintained by groups of users as the
Realtime Blackhole List (RBL). The RBL is updated regularly and can be remotely
accessed and loaded by a system administrator into enterprise routers or message
switch databases.
Although the RBL provides an Internet-level view of untrustworthy sites, an
administrator will still almost certainly wish to implement local (i.e. to Acme)
authorisation policies. Such policies can be based upon message domain and/or user
name(s), as we shall now discuss.

Domain Authorisation
It is possible and useful to have a trust policy based on the domain in which the
message originated. For example, to reject messages coming from the spam.com
domain irrespective of the domain of the connecting message switch bigisp.com.
This authorisation should be capable of being performed independently of the
connecting message switch identity check or combined with it. For example, the
combined approach allows the following type of check:
Accept only if the domain of the originating message matches that of the connecting
message switch.
Note that this is very useful in circumstances where there are known spam problems
with a given domain. However, it is not sensible to employ this rule as the default case
because much legitimate email will not have a match between the remote message
switch and domain name. For example many Internet service providers have a central
message switch which relays email messages for all their customers domains.
Domain authorisation is a useful technique but it does suffer from the drawback that it
is possible to forge the domain information as this is contained within the message
header in the ’From’ field. However, at the moment, this still traps a majority of spam
attempts.

Mailer Domain Authorisation Features

Mailer offers the ability to perform the following types of message
switch/domain authorisation
1. Accept mail from anybody
2. Accept mail from mail host/domains that are explicitly listed ( a "trusted" set
approach)
3. Accept all mail except from mail host/domains that are explicitly listed ( an
"untrusted" set approach)
The following diagram shows how a default policy of accepting all connecting message
switch requests can be overridden by a specifying a set of untrusted sites.

The default rule setting could be changed to reverse the accept-all-but policy to a
reject-all-but policy. Note that rejection can be with Delivery Report (DR) notification
or without. The constraints field allows the administrator to only allow messages from
a domain associated in some way with the connecting message switch host.
For example, the first exception line in the table allows only the connecting message
switch mailhost.beta.com to pass on messages that originate in the beta.com
domain. This enforces the policy that the originating user must be part of the beta.com
domain. For example, this stops other domains from using the beta.com domain to
relay messages to Acme on their behalf - i.e. masquerading behind a legitimate domain
(spammers frequently use any available unprotected Internet message switch for
relaying).
The next diagram shows how the Domain authorisation policy can be set. An additional
option allows relaying of external domain messages (this topic is discussed later). The
local option identifies an intra-company (i.e. Acme) domain.

A subtle point here is that the domain policy allows an additional restriction on
spammers. If a spammer forges their address domain to be
beta.com(e.g.fred@beta.com) and relays the message to Acme via other domains than
beta.com (to escape detection) then the Acme message switch will reject the message
because the constraint only allows the connecting message switch to be in beta.com.
Note that this is a different rule to the similar looking one in the previous diagram. The
Domain rule will be invoked for messages coming in from all connecting message
switches, not just the mailhost.beta.com message switch.Mailer also provides the
facility to define Groups. Groups allow sets of users, domains and routes to be associated
with a specific authorisation policy. Thus Mailer can be simultaneously executing
different authorisation policies on behalf of different groups. The Domain Authorisation
Policy diagram illustrates a simple example of Groups via the pre-defined group "local".
This feature will be used in the discussion of User Authorisation.

User Authorisation
Often, as an aid to spam control, an enterprise may wish to impose on the email
network the same kinds of administrative control that have been devised for paper
systems. For example, restrictions on who may send to whom (i.e. mirroring the
organisational hierarchy), or sign-off routing (i.e. so that outgoing email has to be sent
by authorised individuals).
Even if only simple versions of these kinds of activities are contemplated, it is
necessary to be able to set authorisation on a per user basis. Permissions will typically
relate to who may communicate with whom (e.g. ability to send internal email only as
opposed to internal and external email authorisation) and by what route. These kinds of
authorisation usually require that the administrator has the ability to define groups with
differing communication attributes and assign users appropriately.
In addition to the above, it may be necessary to associate authorisation processes with
the kinds of messages that individual users may send (see content authorisation later).

Mailer User Authorisation Features

Mailer allows individual users to be subject to different authorisation policies.
The following diagram illustrates a simple example of user authorisation. Each user
listed in the table can be given authorisation facilities ranging from: reject (no
messaging facilities), local (send and receive messages within the local domain only),
local plus receive external messages, send and receive messages both locally and
externally.

Note that the context of local is defined by the domain(s) marked local in the Domain
Authorisation diagram. If the Domain Authorisation and the User Authorisation
configurations conflict, the User Authorisation will override Domain Authorisation.
This is designed to allow exceptions to domain policies for specific users. For example,
to allow communication with friend@spam.com and thereby override the blanket
domain ban on spam.com.

Relaying
In the introduction, we identified relaying as the third of the possible actions that the
Acme message switch might take, along with rejecting and delivering. There are two
situations in which relaying might occur:
• Enterprise Gatewaying / Border Management
• Cooperative Message Transfer

Enterprise Gatewaying
It is usual for the Enterprise Intranet to be shielded from the Internet by both network
protocol firewalls and application gateways. Mail gateways act as relays for mail to and
from the internal systems. This allows, as we have discussed, common authorisation
policies to be established at the network boundary of the Enterprise.
This makes for much easier administration than ensuring that all the Intranet
departmental message switch hosts have the same policy. It also allows message
headers to be rewritten such that a consistent mail domain address format is propagated
beyond the intranet and indeed that the internal structure of the intranet is not revealed
to the outside world (reducing further the potential security loopholes). An additional
use for relaying is when gatewaying between different network technologies (e.g. X.25
to TCP/IP) and/or different messaging formats (e.g. Internet to X.400). Needless to say,
Mailer makes an excellent firewall or gateway as well as being capable of
being deployed as a general message switch.

Cooperative Message Transfer

Internet message switches have traditionally been configured out-of-the-box to allow
external organisations to relay mail through them as part of a cooperative ethos of
getting messages delivered. This makes sense when a remote host might be unavailable
and a message can be moved to another message switch that is closer (e.g. to a host on
the same continent as the target host) to the target than the originating message switch.
However, spam has made this cooperative ethos difficult to sustain. Consider the
following common scenario.
A spammer sends one message every 30 seconds to the Acme message switch with 250
user addresses in each message header. If the Acme message switch obligingly
generates 250 copies of each message and sends them onwards then the following
situation will pertain.250 users will be very unhappy that Acme has unwittingly played a
part in junk mailing them (and sue?) The Acme message switch administrators will
wonder why their machine is running slowly and they cannot get their own messages
delivered The Acme message switch may become blacklisted by other servers which will
then refuse to accept connections from Acme for legitimate business messages. (One of
RBL’s principle purposes is to list "open spam relays".) This identifies some of the
problems that exist when messaging relaying is employed. Thankfully products are now
available, for example Mailer to provide protection against these very issues.

Mailer Relaying Policy Features

As shown in the Domain Authorisation diagram earlier, Mailer allows the
default relaying policy to be set to:
• Default to Do-Not-Relay
• Default to Relay
Exception lists are allowed which in association with the first option implement a
trusted exceptions policy, and with the second an untrusted exceptions policy.

Security Loopholes
Make sure the following common host and TCP/IP services security loopholes are
closed, especially on UNIX systems:
1. Insufficient data backup
2. Weak password policies
3. Absence of host-based alert systems such as COPS and TRIPWIRE
4. Unpatched host operating systems and applications
5. Vulnerable TCP/IP services, especially simple mail transfer protocol, network
information service, network file system, and FTP

Message Content Authorisation

So far we have considered authorisation based on issues relating to the domains
through which a message has traveled before arriving at Acme and specific user
sending/receiving privileges. Additional important authorisation processes may be
based on the contents of the message. We shall give a brief overview of content
authorisation here.
There are several criteria by which the content of a message may be subject to
authorisation:
• Size
• Security Attributes
• Content Type Routing
• Content Screening

Size
It is usual to be able to define the maximum size of a message. This is useful in
situations such as (i) a message may be routed over a chargeable link and messages of
tens of megabytes need to be stopped, or (ii) the remote message switch or its attached
network is not able to cope with messages that contain large attachments and the result
will be that users are denied service.

Security Attributes
It is now possible to transmit messages that are digitally ‘signed’ as an integrity check
- i.e. as a means of notifying the receiver that the message has been changed or
corrupted. In addition, certain kinds of secure messages can carry a security label in the
message header that the message switch can use to decide whether the receiver has
sufficient authorisation for the message to be delivered to him/her.

Content Type Routing

In the User Authorisation section, the subject of authorisation by user was briefly
mentioned. In addition, it may be necessary to authorise on the basis of the type of
message content. For example, Internet messages may be sent by a given user, but not
X.400 messages. Alternatively, it may be necessary to restrict the types of body parts
that a message may contain because the receiver may not be able to handle them.

Content Screening
The most common type of content screening involves the scanning of the message and
its attachments for viruses. These either cause the message to be rejected or the
message switch substitutes the offending message part for a default message part (e.g.
"virus found here").
In addition, it is often required to detect specified types of information content. For
example, an enterprise may wish to check outgoing (or incoming) messages for
commercially sensitive or offensive words and reject or edit the message accordingly.
Although these techniques provide protection again casual offenses, it maybe difficult
to cater for the determined (ab) user who may use private, non-sensitive code words.
New developments within the understanding of the ideas within a document has
enabled to provide the ability to route email messages based upon the ideas
within a message. This technology moves beyond simple keyword matches to full
content understanding.

Header Screening
There are ongoing developments regarding the addition of specific fields within the
heading of messages, which identify the type of the message. An example would be to
identify unsolicited bulk email (UBE, also known as spam). Thus, message switches
can screen messages based upon the presence (or not) of certain information within the
heading.

Mailer Content Authorisation Features

Mailer supports most of the above kinds of content-based authorisation in the
off-the-shelf product. However, due to fact that enterprises often have very different
specific requirements, advanced training or consultancy is usually suggested.
Summary
This paper has provided only an introduction to a very complex subject.
Mailer has a number of features that cater for more complex cases. For example, a
given Mailer can handle multiple mail domains each with their own separate
authorisation policies. For more information about authorisation issues contact