Here's why we are converting our "monolithic" Imail/Declude servers to a multi-tier 
store & forward configuration as follows:

Incoming MX servers:

Receives inbound mail from Internet
Runs Declude anti-virus to delete all viruses (single global config)
Forwards all mail to Anti-spam servers

Anti-spam servers:

Receives de-virused email from MX servers
Runs Declude junkmail with per-domain settings 
Forwards mail to mailbox servers

Mailbox servers:

Runs IMAP, POP, WebMail Mailboxes
Delivers outbound mail directly for -
  Locally originated email
  Internet-originated but SMTP authenticated remote mail


The reason for this migration is a "love/hate" relationship with Ipswitch Imail:

It's cost effective and has the features we need (plus the support for Declude 
plug-ins), BUT

It is a CPU hog - WebMail or IMAP often spike the server
It has been buggy at times (recent IMAP problems for example)
It cannot be clustered - all functions for a domain must be on one server
It does not have any HA (high-availability) or redundancy capability

By offloading incoming MX, virus scanning, and spam blocking to other servers we are 
creating a much more robust configuration.

Massive virus attacks or spam attacks will not affect our user's ability to access 
their existing email boxes via pop/imap/webmail.

Scalability -- as virus and spam continue to grow much faster than real 
mail/mailboxes, we can put extra processing power where it is needed most.  Currently, 
we had to prune our Declude rules/filters because they were spiking our boxes to 100% 
cpu too much.

High-availability -- (partially)  By isolating the mailbox functions 
(pop,imap,webmail) and keeping relatively simpler inbound handling/queuing on separate 
servers, we preserve the ability to receive inbound mail even if we have 
crashes/bugs/failures in mailbox processing.

For our needs, we prefer several affordable servers distributing the tasks than one 
mega-server box -- better protection against human errors/mistakes which are more 
likely than hardware failures day-in and day-out.

Finally, by modularizing the processing, we gain a little more freedom - in the future 
we might choose to replace one of the processing nodes with a different 
vendor/technology.  Replacing one function is easier than trying to do an en masse 
migration the entire mail system.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Tolmachoff (Lists)
Sent: Wednesday, June 23, 2004 6:01 PM
To: [EMAIL PROTECTED]
Subject: RE: Re[2]: [Declude.JunkMail] AutoWhite by eServices

> A client has a pair of generic incoming MX servers.  These then feed
> into a Declude server, storing and forwarding to the mailbox server.
> The mailbox server does its own outbound mail.

> I'd like to know if it will ever be possible to do this, perhaps by a
> routine that can parse the log on the mail box server(in the case of
> AutoWhite) or by remote interrogation of web address lists(in the case
> of Declude's whitelist feature).  I fear that not enough people are
> using Declude as a store and forward device and therefore demand will
> not be high enough to justify the change.

The issue as you have pointed out is that both Declude and AutoWhite for
Declude need to see both incoming and outgoing to work.

Generally speaking, it appears that most configurations where Imail/Declude
scan the incoming only for a S&F domain are in corporate configurations
where it is used as a cost effective well balanced tool to fight incoming
viruses and spam. I myself would like to understand why the company policy
or network admins feel this is the way it should be. Having Imail/Declude
process both incoming and outgoing has multiple benefits.

You are correct in that there has not been enough interest/request for this
kind of function, and to be broad to be used enough to be able to work with
multiple e-mail servers that are handling the actual e-mail would create a
lot of overhead. If the different types of e-mail servers, such as Exchange
or Postini or Mdameon had some common form of logging that would be one
thing.

If there is interest in say one flavor of server, say Exchange, for this
function, I am open to consider looking at ways to make it work.

John Tolmachoff
Engineer/Consultant/Owner
eServices For You
.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type "unsubscribe Declude.JunkMail".  The archives can be found
at http://www.mail-archive.com.

Reply via email to