Home
> Cover Story
Evading
the evils of e-mail
E-mail
is billed as a productivity tool, but there are times when
it is difficult to decide whether it is supposed to work
for or against you. by Graeme K. Le Roux
The
first problem with e-mail is its unreliability. Frequently,
users don't get mail, can't read it and/or can't be certain
the mail got through, or the e-mail bounces back and is
flagged as undeliverable. Addressing these problems starts
with your Mail Exchange (MX) record; this is the DNS record
which tells other systems on the Internet or your internal
Intranet if you use a DNS service on it where to send
e-mail for a given domain.
In essence, an MX record is a list of mail server names
which other mail servers will try to send mail to, starting
at the top and working down. The first entry in an MX record
will be your primary mail server and the second will usually
be your ISP's mail server. This means that if someone sends
you e-mail, it will go to your mail server unless that server
is unreachable (Internet link down, mail server off-line
or busy, etc.), in which case it will go to your ISP's mail
server, which will eventually relay it to your server.
Your primary mail server's job is to send and receive external
e-mail and to forward e-mail between internal mail servers.
The primary mail server may also act as a translator between
Internet-based SMTP and proprietary internal systems like
MS Exchange or other standards-based system like a host-based
X.400-based system.
It is the secondary e-mail servers, which might be departmental
or site based, that host users' mailboxes. With this sort
of system design, both internal and external users will
always be able to send mail because there is always a place
to forward it, unless all secondary servers are disabled
an unlikely prospect.
Having multiple servers also reduces the processing load
on any one server and thus minimizes delivery delays. Secondary
servers can be set to provide automatic delivery acknowledgements.
Two other common e-mail problems are mail servers that place
a limit on message sizes and mail clients that cannot support
complex message formats. One way around this is to encourage
users to keep attachments under a megabyte in size, and
send multiple attachments separately. If users need to deal
with multiple attachments on a regular basis, then compression
software, like WinZip, can be used to reduce the bulk size.
To address format issues, stick to simple SMTP/MIME encoding
with either text or HTML formatted messages. In addition,
use a consistent
e-mail system for both servers and clients to eliminate
most of the problems resulting from users not being able
to read mail.
Configuring Security
Enforcing security is the next biggest problem for
e-mail systems. Since e-mail provides a path for information
to leave your company en masse, the advantage of the system
design illustrated here is that the company's primary mail
server becomes a single point at which you can log all messages'
source, destination and content.
Logging won't stop users from compromising company information,
but it will allow you to do damage assessment and have some
idea of who sent what to whom. Publicizing the fact that
all e-mail is logged will also discourage users from using
e-mail for unauthorised propagation of sensitive, defamatory
or offensive information.
Your primary mail server is also the point at which you
deploy your virus wall, which checks all e-mail messages
against a database of virus patterns. It is important to
configure your virus wall to scan all mail messages whether
from external or internal sources. Further, having an infected
workstation send a virus to one of your clients could be
embarrassing.
Nevertheless, no matter what measures you take, expect to
get a virus sometime, like when a virus is newer than your
virus definition file. Thus, besides ensuring regular virus
updates, what is also important is that you can isolate
and remove infections preferably without taking the entire
network off-line.
The procedure to kill an e-mail borne virus in the network
is described in the box. This procedure will work no matter
how badly infected your network is.
In addition, there are other configurations that can be
done to the e-mail system to help contain virus infections,
or at least slow them down. First of all set mail clients
such that they do not automatically execute attached files,
like VB scripts, and .exe files. Such files should be first
saved to disk and scanned. A policy that sets email clients
to prompt users to save the attachment before running them
can help reinforce this message. Another good practice is
to set applications, like MS Word, to prompt users before
launching macros.
In addition, set all your mail servers to delay forwarding
mail to the primary mail server every couple of hours rather
than immediately. This way, a virus which infects one of
your secondary mail servers will take between, say, two
and four hours depending on the delay you set to propagate
to another one. This gives you time to discover the virus
and stop propagation by shutting down your primary e-mail
server.
Another security issue with e-mail is the fact that you
have to open a TCP/IP port to send and receive e-mail. Just
because SMTP uses TCP port 25 does not mean that a hacker
can't use the same port for something else. The only way
to directly stop this is to limit the SMTP command set which
your primary mail server will support.
Your primary mail server is the only server on your network
which should be able to communicate with the Internet via
SMTP. In fact if you use something like X.400 internally,
no other server or client should be able to communicate
via SMTP at all which is a very good reason to use such
systems.
Proxy-based firewalls guard against non-SMTP traffic on
any port designated as being for SMTP by examining each
packet's header and restricting the SMTP commands. But although
SMTP proxies work well, they are relatively slow and expensive.
On the other hand a filter-based firewall will restrict
access of packets with SMTP headers to designated mail ports.
In the configuration cited here, compromised access to the
primary mail server does not provide an intruder with access
to any other host on the network.
It may provide access to other mail servers but if you use,
say, X.400 internally this will not be the case as the primary
mail server's access will be restricted to the system interface
for a server's message store. In short, given a reasonable
level of host security, there is little an intruder might
gain from compromising a primary mail server.
Unauthorized SMTP relay is one risk. An intruder could enable
this feature and then hijack your server as a relay. But
remember you are logging all e-mail; you can set your log
utility to export logs, which means an intruder's every
action is recorded in a way which cannot be prevented or
erased.
The final group of problems is associated with handling
large numbers of e-mail on a daily basis. To address this,
choose a mail system which allows users to easily write
rules which automatically sort mail into separate folders
based on source, priority, or content.
Also, set individual folders to delete or archive (in searchable
databases for six months) e-mail on a monthly basis. This
will cut your storage overhead and make it easier for the
user to find current mail. Set your mail clients to present
new messages with a three-line preview, which can help users
decide what to do with messages more efficiently.
Another good practice is to learn to ignore mail while you
are doing something else. Disabling new mail audio warnings
and suggesting that users read mail only first thing in
the morning, after lunch and at the end of the day, can
help to reduce distractions. Introducing a delay into mail
forwarding will also help.
These simple steps will help your users avoid getting buried
by e-mail. You can also encourage users to forward mail
to an assistant when they are outstation,as well as set
automated out-of-office responses. Remember, e-mail is supposed
to help users not hinder them.
Graeme K. Le Roux is the director of Morsedawn (Australia),
a company which specializes in network design and consultancy
and writes for Network Computing-Asian Edition. He can be
reached at graemel@moresdawn.com.au
Send your feedback to editor@networkmagazineindia.com
To
kill a virus
The
object of this procedure is to stop an existing infection
by a new virus from spreading and to
eliminate it from a system with minimal disruption
to users' normal activity. Systems which allow
administrators to push virus updates down to
client PCs and additional server based anti-virus software
can substantially cut the time required for this procedure.
Internal firewalls which allow administrators to selectively
disable specific types of network traffic are also extremely
helpful in large systems. Assumptions: Mail system, anti-virus
software deployed on both the primary mail server (as a
virus wall) and on all PC clients; real-time scanning supported.
1) User reports a virus infection.
2) Disable mail transfer (receipt and forwarding) at primary
mail server. Inbound Internet mail is held by ISP's mail
server. Outgoing mail is held at secondary mail servers.
If the virus is of a type which can propagate via data files
then restrict access to data stores to read only. Users
can continue to work on local copies of files but can't
spread the virus further.
3) Get a virus pattern update from your vendor for both
the virus wall and client software. Note that while your
mail server is down, Web access need not be, although care
should be taken to ensure that users do not spread the virus
via Web-based e-mail accounts.
4) Apply the new virus patterns to your primary mail server
and enable internal mail transfer and mail forwarding to
the Internet. Do not accept inbound mail from the Internet
at this time.
5) Secondary mail servers will start to forward e-mail and
the new virus pattern will cause the virus wall to filter
infected e-mail, which will identify the secondary mail
servers which are infected.
6) Starting with the secondary mail server, which is sending
the most infected emails, shut the server down and flush
its e-mail queues.
7) Update the anti-virus software on this server's clients
and run a scan on all local files.
8) Enable the secondary mail server. Enable write access
to all network files.
9) Repeat from 6 for each secondary mail server.
10) Allow primary mail server to accept Internet mail.
