[TriLUG] RHEL5 mail server dreams

[Michael Hrivnak]

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 
hardware.

Michael


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?
>
> Cheers,
> --
> 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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://www.trilug.org/pipermail/trilug/attachments/20080213/f8c2c59f/attachment.pgp>