>I have been administering a webserver/mailserver for our company for several >years. I migrated with iMail from 5.x to 6.x and finally to 7.x. I manage >an unlimited user server that hosts roughly 80 domains with roughly 2000 >user accounts. As it has been mentioned on the list, the bigger I get the >more unreliable iMail seems to become. It doesn't crash all the time, it is >actually fairly stable. My problems occur when the box experiences heavy >traffic.
I'm not convinced that supposed instability of Imail is due strictly to Imail. I suspect MS's API and filesystem and tcp/ip stack are all accessories to the crime. ColdFusion was severely hobbled for a long time (1996 to 1998? or longer? ) due to ODBC bugs and memory leaks. >I am redesigning the system and putting it on a dedicated box. Imail should be on a dedicated box. (sorry about people running co-lo) >I am no longer going to use the iMail user database this is the fastest >but going to have a separate SQL server that will manage my users. too bad there's not some way to run an external client management database and have it update Imail's user database witht diff's (delete/add accounts + domains). yes, keeping duplicated databases in sync is a pain, but the parallelism allows to pound either database severely (even have it fail) without bothering the other copy. >I am considering building 2 or 3 IMGate machines to support iMail. You only need one for your traffic of 2000 users, with a second one, preferably off-site, as backup MX. >This ought to be an optimal configuration for a single iMail server, right? Using SQL as external database has some penalties vs Imail registry, but since with only 2000 users, you are small Imail server that is not going to stress current or recent hardware, if you set it up correctly. >In addition to opinions on using IMGate to offload SMTP processing and >making use of external mail queues IMGate shortens the lifetime SMTP/SMTPD sessions as executed by Imail. For sending mail, Imail SMTP does no DNS lookups since it sends to the ip of IMGAte. IMGate is always ready to "sink" messages as fast as Imail can "source" them. IMGate can run 100's of SMTPD receiving processes, if IMail's queue processing was aggressive enough to run 100's of SMTP sending processes. :)) IMail's queue will be empty since there will be no deferred deliveries due to IMGate always accepting the mail (that's acceptable to the restrictions you put in IMGate). For receiving mail, IMail's SMTPD sessions will also be as few and as short as possible, since incoming mail is from IMGate, and not from slower, jerky, connection-losing Internet. You can move all your Imail per-server filters to IMGate. If you�re running 100's of rules, this can be a huge relief for IMail. IMGate is a very effective anti-infection device when header and body filtering can be used to block to fixed strings (I_LOVE_YOU) and dangerous attachments (essentially including, at your option, all attachments except .zip, including those with multiple file extensions like *.doc.exe, etc) IMGate will also enforce max msg size limits before over-sized messages hit Imail. IMGate will reject 20% to 50% on incoming mail due to RBL checks and DNS validations. You can remove SMTP AUTH and users' outbound traffic from Imail and use pop-before-smtp on IMGate. You can remove all ETRN and mail relay traffic from Imail and move it to IMGate. The above list is incomplete. :)) Len http://MenAndMice.com/DNS-training http://BIND8NT.MEIway.com : ISC BIND for NT4 & W2K http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/
