-
-
   Home
   Archives
 About Us
   Advertise
 Feedback
 Subscribe

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.

<< >>

- <Back to Top>-  

Copyright 2001: Indian Express Group (Mumbai, India). All rights reserved throughout the world. This entire site is compiled in Mumbai by The Business Publications Division of the Indian Express Group of Newspapers. Site managed by BPD