You configuration is fine with one recommendation: You would off load
additional workload from the main server by having it send all outbound
e-mail through a smart host, that being the Ant-spam server. This way, the
server does not have to do outbound resolution and communications with all
the other Internet servers, it simply sends all outgoing to the next server.
They way you are tiering your servers is actually a recommended way once a
server reaches saturation. Example, a client I consult for is in the process
of splitting the work load from one server to 2. The front server which will
be configured for S&F for all domains and will do all JunkMail scanning and
do all the receiving and sending to the Internet. The main server will do
all Imail functions and Declude Virus Scanning. But again, all incoming and
outgoing will flow through the front server, the main server sending all
outbound to it to offload that work from the main server.
John Tolmachoff
Engineer/Consultant/Owner
eServices For You
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:Declude.JunkMail-
[EMAIL PROTECTED] On Behalf Of decjunkmail
Sent: Wednesday, June 23, 2004 7:40 PM
To: [EMAIL PROTECTED]
Subject: RE: [Declude.JunkMail] AutoWhite by eServices
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:Declude.JunkMail-
[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.
---
[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.
.
