For us who use both IMgate and Declude it would be much better if you 2 gouys could coorporate
Scott and I have cooperated in the past, but just like our products, we are fully de-coupled and independent. Declude and IMGate achieve excellent results independently, because they are fully de-coupled by the SMTP protocol.
We did have one coupling experiment where msgs that got through IMGate but then were rejected by Declude/sniffer were harvested from the declude log files. The information (sending IP, sender domain, helo hostname) was "fed forward" to IMGate's access policies so IMGate could block them first.
The benefits were quite small since so little got through IMGate. IIRC, IMgate rejected 27K/day, and then Declude/sniffer rejected another 1k/day. Since the client 1) already paid for declude/sniffer (now to catch only the 1k) and 2) the IMail server had already enormously benefitted from the 27K IMGate rejects not reaching IMail, the client decided the complexity of the declude-feed-forward-to-IMGate was not worth the benefit. IMGate was blocking 96%, and with coupling with Declude, IMgate rejected maybe 1% or 2% more. Law of diminishing returns.
and make a solution with did the best of both products. Yes I know I want a lot more than i can get here.
In today's nightmarish SMTP environment, the best solution is always a defensive MX in front with the mailbox servers behind. Which brand of MX and which brand of mailbox server doesn't matter. It's the 2-layer architecture that produces the benefits.
To be banal and obvious, the more that can be moved off the mailbox server to other boxes, the better. The multi-box, multi-layer approach is the most scaleable. Your problem was that the one-box approach simply did not track your increase in volume.
But the fact is that Imail with declude together killed our servers because of a huge amount of mails coming through to us.
not an uncommon experience. many IMGate users came to IMGate because their mailbox server was overwhelmed doing everything and/or the admin simply refused (financially, philosophically) to have their mailbox server accept see 100% of all traffic (as MX), then reject 70+% of the total msgs. Many IMGates are rejecting about 90% of inbound. Because IMGate rejects predominantly after RCPT TO: where IMail/Declude reject after full DATA reception, IMGate also minimizes bandwidth lost to spam. Some big IMGate sites are saving bandwidth that is equal to a T-1 or more.
So more hardware, better hardware, new version of Imail and so on nothin absolutelu nothing helped.
While a lot of sites do manage to tweak and tune and optimize to scale up Imail/declude/sniffer/windows/RAM/disk, a lot of IMGate/Imail sites, having spent significant period of time with Declude and Ipswitch and major $$hardware upgrades, simply cannot get the one-box solution to scale, just like your case.
Everybody said its not us its
the other one. So what I did was to put Imgate in front an backend with Imail between and this is actually the solution which
helped.
When the one-box setup poops out, the two-box setup has never failed, in my experiences of the last several years, to be the solution.
But now the only thing I do is trimming and blocking around 1.5 million mails on my front and I could if i wished to
block a lot more.
Why don't you do it? With 1.5 million rejected by IMGate, how many more are rejected by Imail/declude?
Declude and Imgate in togethernes on the frontend server would be heaven.
Declude and IMGate run on different OSs. You could go to a 3-layer setup:
1. IMGate as MX (this of course MUST reject unknown users)
2. windows/Imail/declude/sniffer + AV as relay-only box (this step could also be opensource)
3. Imail box server.
Len
_____________________________________________________________________ http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
To Unsubscribe: http://www.ipswitch.com/support/mailing-lists.html List Archive: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Knowledge Base/FAQ: http://www.ipswitch.com/support/IMail/
