Messaging Server: Correctly Deploying the MTA for Anti-Spam/Virus Scanning

According to many in the know, scanning for spam and viruses has now become the most expensive operation that the email infrastructure has to perform. So setting up this infrastucture, correctly, from the beginning of a messaging deployment, has become more and more critical.

The Sun Java System Messaging Server 6.3 Deployment Planning Guide has some basic information to assist with this deployment endeavor. For a quick look, check out the following figures:

Here's some more information from our experts on this topic:

Sun has implemented the Messaging Server MTA to be able to "call out" to third-party spam/virus filter packages, like BrightMail and ClamAV, from within the MTA. Specifically, this happens within the SMTP server. The reason for this work is to enable putting a spam/virus filter package on an SMTP host--especially a separate SMTP host--deployed "in front" of the Messaging Server MTA.

From a Messaging Server perspective, it is very important to have the MTA do its address validity checks as soon as possible, before a site ever "accepts" (at an SMTP level) a message. That's why you should deploy the Messaging Server MTA "on the edge," so to speak,and then call out to the spam/virus filter package during the initial SMTP session.

Comments:

Sorry to disagree, but regarding your comment on "Correct" and "Incorrect" deployment of a spam/virus firewall, I call bullshit. If you are using a dedicated spam/virus firewall that is capable of using ldap to determine valid user accounts from your directory, sticking it in front of your MTA is the more correct approach. The reason is that your MTA is freed from the requirement of dealing with every single spam message, handing it off to the spam filter, and you still get the benefit of dropping mail to invalid recipients as early as possible. In that scenario, all the spam and viruses are gone from the incoming mail stream before they hit your MTA and your MTA only ever has to deal with legit mail.

Posted by Scott Flowers on November 08, 2007 at 05:24 AM MST #

Sorry to disagree with Scott. Most anti-spam/virus filters or firewalls don't support even a basic set of SMTP extensions, like DSN and SIZE. Furthermore, in this age of consolidation and data center power consumption problems, why put an extra box in front of the MTA if you can smoothly integrate the AS/AV functionality with the MTA on the same system? Plus, a separate AV/AS box creates yet another place where problems can show up, where queues can grow, which has to be monitored, which has to be duplicated (for contingency planning), which has to be duplicated (in your test environment) etc. etc.

Posted by Rolf E. Sonneveld on November 08, 2007 at 05:40 AM MST #

Scott,

I'm actually working on a white paper that provides a lot more detail on why Messaging Server should be architected as I briefly summarized in this posting. But en bref, the idea is "validate then scan."

I'll try and get this paper out sooner now that I see the topic has gotten some heated interest.

Posted by Joe Sciallo on November 08, 2007 at 06:45 AM MST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today