SQL Server Magazine

User spam reporting lets users forward spam messages to the appliance for inclusion in the spam filter list. To make this method work, you need to use the SMTP address that you gave the appliance to set up an Active Directory (AD) contact or custom recipient for spam reporting in the Global Address List (GAL).

You can specify what happens to the messages that each detection method catches. The IronMail can tag the message subject with a user-defined string, delete the message, shunt it to a quarantine queue, or generate a log entry and let the message through.

I set separate subject-line tags for different detection methods so that I could see which filters the software applied to which messages. After I tweaked the filters, the IronMail classified more than 200 messages as spam over the next week. Of those, about 85 percent actually were spam. That's solid performance, and the IronMail software let me easily adjust settings to the desired level of aggressiveness.

The ability to set a subject-line tag for each type of spam lets you easily use Microsoft Outlook rules to filter spam. However, I found that the IronMail's initial filter settings blocked too many legitimate messages. For example, DCC filtering tagged messages from The New York Times and The Wall Street Journal news-alert services as spam, and the reverse DNS lookup blocking stopped most mail I was receiving from a discussion list that Microsoft's Office group runs. Interestingly, the IronMail didn't report catching any spam through the Razor network. This finding might have been a result of the IronMail's queue approach to message filtering. A message that one filter rejects or tags isn't queued for evaluation by other spam filters, so the Razor filter wouldn't have had a chance to tag spam if the other filters did so first.

I could have set the filters to quarantine rather than tag messages. However, I would then have had to use the Web-based interface to review the quarantined messages. That capability is useful for small sites, but it isn't something that administrators of a 50,000-seat Exchange shop are likely to want to do.

I had one serious problem, which was of my own doing but annoying nonetheless. My mail servers are set up to accept mail for several inbound domains, and I use Exchange 2000's relaying-control features to let them do so without opening relaying to the world. The IronMail uses one check box to control relaying; if you select that check box, you tell the device to act as an open relay. You can control which domains are treated as inbound, but neither the interface nor the documentation make that clear, and you apparently can't configure the IronMail to let only authenticated users relay. Because I set up the appliance as a relay, a couple of the Internet's automatic relay blackhole scanners blocked my server's IP address, and I had to manually reset the relay configuration and request a rescan.

The IronMail's antivirus feature uses the Sophos scanning engine and quarantined all infected messages presented to it. Inexplicably, my unit was set by default never to automatically check for updates, but checking for new updates manually is easy. When I turned on automatic signature updates, I found that the default interval is 24 hours. That's a long time when a virus is spreading, so I'd suggest reducing this interval.

Policy-Based Management
Although most organizations have ad-hoc email policies in place, Exchange's tools for controlling who can send mail and under what conditions are relatively weak, and setting policies that consistently apply to all email users is difficult. In this area, the IronMail software shines. The appliance offers a wide range of policy controls, including the ability to

• control inbound and outbound relaying by IP address or domain name—a feature you'll welcome if you want to designate the IronMail as the relay target for your mobile and roaming users.
• require or prevent the use of Transport Layer Security (TLS) and SSL for particular domains, letting you make sure that all mail to certain domains is encrypted during transmission and that mail to other domains remains unencrypted so that you can monitor it.
• rewrite outbound-mail headers to reflect a standardized set of headers. For example, if you have two SMTP domains for your users—northamerica.fabrikam.com and emea.fabrikam.com—the IronMail can rewrite all outbound mail so that it appears to come from (and has a reply address of) user@fabrikam.com.
• require, prevent, or allow Secure MIME (S/MIME)­encrypted mail to specified domains, from specified senders, or to selected recipients. This feature is terrific for those who want to enforce encryption for sensitive traffic without requiring or allowing encryption for general use. In my tests, the IronMail correctly blocked unencrypted mail addressed to domains for which encrypted mail was required. One missing feature is a gateway-to-gateway system that would accept unsecured messages, then automatically sign or encrypt them before delivering them to the remote gateway.
• defer delivery of messages larger than a specified size until a specified time.
• delete, copy, reroute, log, or quarantine attachments based on file extensions.
• use customizable dictionaries to classify messages as pornography, spam, confidential or sensitive, or malicious. As with most keyword-based scanners, however, spammers can easily obfuscate content to slip it through the IronMail filter—think of all the spam you've seen that has something like F+ R+ E+ E+ in the subject line.
• add disclaimers to particular domains. Unlike several competing products, however, the IronMail can't apply disclaimers to mail sent from or to individual users.
• monitor the delivery of mail to particular domains.

You can also specify recipients or recipient domains that are permitted to bypass the policy restrictions. Email sent to such a user or domain can skip all defined policy checks, which is useful if you use SMTP to move mail between different parts of your organization. However, I would prefer an expanded feature that provides finer-grained control by acting more like a Web proxy, with individual users allowed to bypass policy checks based on the credentials they use to authenticate to the SMTP server.

Prev. page     1 2 [3] 4     next page