[TriLUG] RHEL5 mail server dreams
mhrivnak at hrivnak.org
Wed Feb 13 01:24:00 EST 2008
It's a good idea to do filtering and storage in different places. If your
filters get hammered and build up a queue, you can see wait times go through
the roof. If you store email on the same machine, web, pop and imap access
will be sluggish. If you store email somewhere else, users only might notice
that messages are showing up later than expected.
For the filters, you might go with the old standard of (processors + 1) active
threads at a time. That keeps all of your processors busy, with an extra in
case one process is in io wait.
Most of my spam filtering experience is with spamassassin. Consider disabling
some of the rules based on which are least applicable and most
resource-intensive. I've successfully use file size as a reasonable estimate
of how resource-intensive a rule will be. Also consider writing your own
rules to tweak performance.
White-list with care. It can eliminate lots of unnecessary filtering. But, a
whitelist should not be used when To and From are the same. Lots of spam
uses that trick to avoid filters.
Consider rejecting all mail for which the From domain does not have an A or MX
record. Lots of spam falls into that category.
Whatever you do, keep good documentation. If you need to duplicate the box in
a hurry, you'll appreciate it. On that note, keep good backups. Consider
using snapshots, such as with LVM, to get consistent backups of your mail
store. With something like cyrus, it's ideal to stop the service, make a
snapshot, start the service again (VERY brief downtime), and then do a backup
from the snapshot. If you're concerned about client connectivity being
uninterrupted, consider using an IMAP/POP proxy like perdition.
Lock down access for all authenticated services to SSL only. We've come too
far to have authentication credentials flying around in the clear. There's
just no excuse anymore.
Consider virtualization, like Xen. These days, the performance hit is
minimal. It gains you tremendous flexibility in being able to quickly move
the VM or restore backups to a new host should you have hardware problems.
It also gives you console access if there are ever software problems in the
VM that prevent conventional access. Finally, if you must do filtering and
storage on the same machine, virtualization gives you a way to prevent one
from hogging resources from the other. This also makes it easy in the future
to move one of those VMs to its own hardware, or to move them both to better
On Tuesday 12 February 2008 5:03:12 pm Cristóbal Palmer wrote:
> I've been tasked with authoring a proposal for a mail server, but the
> hardware is currently doing another job and won't be available for
> several months. Consequently I have a lot of time to dream up what my
> new mail server *should* be like. Help me dream?
> You might ask, "What's your volume like?" Dream big. Assume that we're
> getting more mail than sane people would want to handle and that the
> hardware will always be woefully inadequate. Unless you're going to
> buy us a new server, we aren't going to get one. "Don't you have some
> hardware specs for me to work with?" you ask. I do, but I want you to
> dream, so I'm not sharing them. Tell me what an ideal mail system
> would look like if the mail volume is always going to be insane and
> you have to juggle every kind of mail service known to man.
> Ideal dreams are fairly complete (ie. touch on everything, not just
> eg. postfix), have your logic articulated at length, and come out of
> your own experience, not a whitepaper's. Bonus points for dreams that
> make the best use of one box + NFS home directories. Any takers?
> Cristóbal M. Palmer
> http://tinyurl.com/3apraw "They also abandoned other volumes, later,
> while fleeing from the librarians."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://www.trilug.org/pipermail/trilug/attachments/20080213/f8c2c59f/attachment.pgp
More information about the TriLUG