Manage Selection Criteria for E-Mail Spam Filtration

Posted on
Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

If the Internet were more regulated, perhaps unsolicited communication would be adequately controlled. Every Internet domain faces what amounts to a “perfect storm” of e-mail attempts, which can dominate system resources and consume vast quantities of attention from IT staff. Ever-increasing volumes of spam in the client inbox attenuate worker productivity. The vast majority of systems viruses are propagated via e-mail, and this bears a considerable security threat.

In the real world, defensive action must be taken against intrusions. To mitigate the impact of spam pressure on e-mail systems, you must develop a strategy for filtration. The solution scenario includes assessing, planning and implementing requirements-driven systems architecture and services.

Until recently, many businesses haven’t recognized the need to proactively address their emerging spam problems. Typically, the issue waits until it achieves a critical mass of negative impacts—the network is unusable, the server is clogged or a virus has propagated. The result is that the administrator or consultant is faced with the competing concerns of engaging a tactical situation–aiming for immediate results–while doing so within some sort of strategic context.

Tactical Solutions Within a Strategic Framework
Actions taken to stabilize an outage are best selected from within a pool of candidates that exhibit a strong chance of being carried forward for the longer term. Begin by looking at the common architectural layers of systems and services that are possible. (See Figure 1.)

Triage—An ‘On-Net’ Quick Fix
Under outage conditions, stopping the storm is of paramount importance. The length of time taken to achieve an interim filtration point can be a big factor in determining how long other repairs will take. Only one scenario is covered here—possible under only narrow boundary conditions. The problem statement is:

Mitigation Objective: Install a spam filtration device on the local network to intercept and pre-filter incoming messages.

The immediate requirement is relieving pressure on the server. Working with the customer, open a service window for making changes to the network and install a spam filtration appliance. Decisions regarding permanent mitigations can then be made with more leisure.

The limitations for this “quick fix” require that the appliance is on-hand, can be installed in the network where the e-mail server is located and can occupy the public IP address for that server. This is a relatively narrow circumstance. In the presence of other governing conditions, solutions often require changes at the DNS level and therefore take longer. However, with many “legacy” e-mail systems, this process is feasible.

Solution Variation: Implement Off-Net Filtration
Tyrnstone Systems Inc. operates an appliance installed for a client at a collocation facility in Seattle. The client’s business is very mature with many individuals using the same e-mail address for more than a decade, so they experience a ton of unsolicited e-mail. The environment supports staff across a number of locations around the United States and Canada. This is a classic “white collar” knowledge organization, and the business lives or dies with e-mail. The systems supporting the environment date to pre-Y2K.

In this case, the solution required redirecting the MX Record for the domain, pointing it to the device and diverting message traffic bound for the e-mail server. The appliance deploys a mix of specialty filtration and proprietary heuristics. The vast majority of spam is rejected, and mostly legitimate e-mail is “piped” to the target server.

Figure 2 summarizes recent activity. Note the filtration rate. The client’s legacy server and the DSL WAN performance were very positively improved by moving the unfiltered traffic off of their network.

Generally speaking, provided there is more time and comparatively more money in the equation, I recommend directing e-mail to “off-net” services. But doing so can raise e-mail security concerns. As previously discussed, this practice frees server resources and unclogs the WAN. Introducing “off-net” services usually involves changes to the MX records in DNS. Various ASPs (Postini, etc.) present an option, but the long-term costs can be hard to justify.

A simple form of the solution selection process starts with the server, evaluates circumstances and moves ahead along the path of least resistance.

Reciting Best Practices
The objective is to enable functional spam filtration by installing an appliance, software or a service. Let’s assume that the scenario is a proactive systems augmentation and that you’re not working under triage conditions—this is the best of all possible situations.

First you must endeavor to do no harm. At the very least, you should understand the users’ operational schedule and arrange appropriate service windows. Consultants will score points by recognizing and paying attention to change control protocol. If there are none, impose “lite” processes of your own.

It’s best to perform a comprehensive site survey to document pre-existing circumstances, operational conditions and functional requirements. You’re looking for all of the perimeter conditions and basic network parameters, logins, etc. Doing this will form the baseline for your project documentation and will support acquiring the proper solution. As a part of the survey, ensure that connectivity requirements exist—a free static IP address on the WAN, for instance—if you’re deploying a local hardware solution. Reviewing and including the domain host and name server utilities with the host and/or at the ISP is imperative.

Policy Recommendations
Periodic checking for “false positives” is critical. In most cases, the solution will provide an interface to view the list of rejected e-mail and the ability to resubmit manual approvals. Review this log daily until confidence is high that no legitimate e-mail is being filtered. Later, perform this activity weekly. Some time will be required in most cases to tune the system. Be sure the customer understands this aspect fully.

Schedule time at least each week to check in on the solution operations, read the logs for errors, etc. Keep the appliance IOS up to date. You should remain aware of the operating environment and act in the best interest of the business by notifying users and others when updates are available.

The solution provider must push for periodic review to check in on the original assumptions and review requirements. If things change, develop plans to address the new situation.

Many small and medium businesses will look to acquire redundant coverage for critical systems over the next few years. For instance, you can recommend subscribing to a backup e-mail service that permits implementing access under outage conditions. Subscribe to a server monitoring and reporting service. Have critical reports sent to your cell phone via SMS or to an off-site authority via fax.

Installing spam filtration can be a very affordable and effective form of business continuity insurance and a substantial security improvement for small organizations. Intelligent management of this configuration can actually reduce total cost of ownership (TCO).

David Gerhart is CEO of Tyrnstone Systems Inc., an information systems and management consultancy. Gerhart has more than 18 years of experience in systems architecture, implementation, operations and management of technology and information systems in a variety of business environments.


Like what you see? Share it.Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|


Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>