John Jolet wrote:
Two things, well several things, really. You need more than one mail server,
or you need a store-and-forward mx in case your mail server goes down.
Second, I'd make sure you put antivirus and spam guards on the mail server,
and that it's beefy enough to handle the traffic. A good split is to put a
bastion mail server doing antivirus and spam checks, but no user verification
outside the firewall (or inside a non-natting firewall), and have him just
forward everything to a secure mail server inside. put the secure mail
server with a non-routable ip, and the bastion mail server with one public
ip, and one non-routable, to talk to the secure mail server. Make sure both
mail servers are up-to-date and kept up to date patchwise. Run NO other
services (except maybe ssh) on either server.
I'd skip the store and forward, it does nothing for you IMHO. The
default queue time on most mail servers is 5 days. That should be more
than enough time to get your mail server up and running or move your
mail to somehwere else. If 5 days isn't enough time to make
arrangements, then having a backup MX with store and forward would add
some value. However store and forward servers don't allow you to check
your mail from them in most cases so we're talking about no one in the
office getting their mail for 5+ days. I'd definitely make plans for an
outage, but I don't see store and forward as a necessary part of
disaster recovery.
Before splitting your mail up into multiple machines think about the
number of users you have, the amount of mail you get, and what sort of
server you have. A decent sized server can easily deal with a 50-100
person office using webmail, imap, and spam filtering. I'm sure you can
find someway to shoot yourself in the foot and need more servers, but
some simple planning should keep that from happening.
1. Block mail up front.
Use greylisting as it stops spam before it enters the MTA's queue. This
keeps 90% of my spam from even entering the more resounce intensive
filtering processes.
2. Don't use blacklists
30% false positive rate. Comapared to 1-2% for Bayesian or Markovian
filtering.
3. Do some simple check up front, but don't do too many.
Require a helo, reject invalid hostnames, reject unknown domains,
reject non FQDN, and that's pretty much it. Requiring DNS to match and
other checks is something you can do, but I've found that there are too
many poorly configured legitimate mail servers for this to be worth the
hassle.
Protecting your mail server is good, but you need to make that decision
based on how you plan to use it. I've seen offices where you had to log
into the VPN in order to check your mail, much like the system John
described above. I've seen others where it was out on a public IP with
no protection. Personally I go for somewhere in the middle.
1. Firewall
You have one, so no problems here. Do remember that any sort of smtp
protocol inspection usually breaks smpt-auth so you may need to turn
that off.
2. Encryption
You're not going to have all sorts of bearely litterate idiots using
your mail server so you can configure and force all your users to use
TLS with smtp, imap-ssl, pop3-ssl, and actually not run the unsecure
services at all.
3. Webmail and user management
I needed to support webmail and also wanted to use PostfixAdmin as the
frontend to mail. PostfixAdmin allows users to change their password and
set their own vacations which is all stuff I don't have to do anymore.
PostfixAdmin also allows me to create users, aliaes, add domains, etc
without having to deal with phpmyadmin or writing the SQL manually in a
virtual system... you might not need to get that complicated. I'm also
running Horde and did some changes that allow users to change their
password through there as well to keep support requests down. Running
these requires Apache, mod_php, and mod_ssl if you want to force https
for logins and what not. If you're small enough I'd just force https
period.
I suspect that'll you'll need webmail or it'll just be too handy not to
do. Make sure you look into some of the tuning stuff to keep it fast
like imap-proxy.
kashani
--
gentoo-user@gentoo.org mailing list
