> Decided to summarise my quite verbose email after writing it: > 1) What kind of load can Imail cope with, using two postfix helpers
The load will be more determined by the user base than by the gateways, which is one purpose of the gateways. Since all inbound contact is done through the gateways, your exposure to outside influences dominating your IMail machine is limited. So suddenly the issue becomes what is inside. > 2) What's the accepted/preferred way of exporting domains from Imail to > IMGate on a regularly changing config Define regularly. > 3) Preferred AV solution Amavis-new as a filter so that you can use whichever antivirus programs you would like. > We've just recently switched from Merak (www.icewarp.com - tons of features, > poor stability) to Imail. Imail seems fine for the few days we've run it so I decided to just look at their page to see what product you meant, and got: error '80004005' Unspecified error /library/inc/incHeader.inc, line 3 If their mail server is as stable as their web site, I can see why you changed. > far, but it's only on a temporary machine at the moment - taking 30-40% load > on a 2.8ghz/1gb box. We're putting it on a decent spec box soon to replace > this. How is it taking the 30-40% load? I mean, how well is it surviving. The best benchmark to see how well it will work is to watch it do so. > I've got the IMGate postfix config files from Len Conrad, and investigating > putting two Linux (is there any good argument to use FreeBSD over Debian) Four arguments, 1) The original coding for Postfix is done on FreeBSD, 2) The FreeBSD TCP/IP stack has a better reputation than LINUXes, 3) FreeBSD is not a multi-flavor distribution setup, which leads to a more uniform progression, 4) If SCO wins their case against IBM, the LINUX kernel may be rolled back a few years to remove contaminated code. But like all arguments, they are to some extent arbitrary. To look at the counter arguments, 1) It is also well ported, 2) If the LINUX TCP/IP stack was terrible then no one would use LINUX servers, so "better" is relative, 3) Once you know a particular distribution, you have most the same uniform progression, 4) The SCO/IBM case will be argued for a long time, and if it looks bad in the end, things can be changed then. > Is this an unrealistic target? Hope I'm not asking 'how long is a piece of > string' To some extent you are. For the performance tuning you will probably need, read some of the info here: http://www.stahl.bau.tu-bs.de/~hildeb/postfix/ There are other sites out there as well. Search for "performance tuning postfix" in the postfix users archive, and you should get plenty of results. In a nutshell, the #1 thing that slows down postfix is disk IO. The #3 solution is a good disk controller, with plenty of RAM on it, and proper mirroring for speed. NOTE: This is not a RAID 5 setup because that is actually poorer performance for your specific issue. The #2 solution is the same thing, but with another drive for the program and logs, making the mirror the spool and only the spool. The #1 most effective solution is using silicon disks for the spool, which also brings up many other issues that have to do with power outages. > My current conundrum is how to populate the transport and relay_domains > files. Although IMGate seems to be specifically written for Imail (I http://www.smartbusiness.net/imail/ > Final question has to do with AV filtering, and also spam to point. There > are a couple of suitable AV products, my current preferred one through > looking at available information is AVG. Also with spam - what filters etc > are recommended? What kind of mileage do you get from them? Well, for using any RBLs, one tip is to put a caching DNS server on the gateway. If you do automatic exporting of valid users, you can harvest addresses that send to invalid users and be very effective at building client block lists. No matter what you chose, expect false positives, and implement a policy for dealing with them. How many false positives will be required before calling something a "bad test" will need to be determined by you. --Eric
