I thought I sent a reply that the form was blank. John Tolmachoff Engineer/Consultant/Owner eServices For You > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:Declude.JunkMail- > [EMAIL PROTECTED] On Behalf Of Greg Foulks > Sent: Friday, June 25, 2004 7:03 AM > To: [EMAIL PROTECTED] > Subject: Re: [Declude.JunkMail] AutoWhite by eServices > > John, > Did you guys ever get my Demo request form? > > Thanks, > Greg > > John Tolmachoff (Lists) wrote: > > >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. > > > >. > > > > > > > > --- > [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.
