[TriLUG] seeking advice for a bullet-proof mail server

Aaron S. Joyner aaron at joyner.ws
Fri Nov 5 10:49:23 EST 2004


Joseph Tate wrote:

>On Fri, 5 Nov 2004 09:38:17 -0500, Ryan Leathers
><ryan.leathers at globalknowledge.com> wrote:
>  
>
>>Does anyone have a good suggestion for me to create some redundancy using
>>only two hosts?  FYI the hosts themselves are solid hardware with mirrored
>>disks.  I also have LVS directors in place so that option is definitely on
>>the table in addition to MX record tricks if I can just determine how to get
>>the same data on both hosts.  I'm also open to suggestions other than qmail
>>if there is a good redundancy story specific to some other solution.
>>    
>>
>
>The SMTP protocol supplies the necessary redundancy.  A secondary MX
>is usually one that is contacted only if the primary MX cannot be for
>any reason.  In that case the secondary queues mail and forwards it
>when the primary comes back on line.  No need to synchronize content. 
>I have this set up for my home operated mail server, and used it at my
>last job using a 500 MHz PIII throwaway PC as the secondary MX.  Now,
>if you want redundancy on the POP/IMAP end, that's a different story,
>but you weren't clear on that, and in fact, in talking about MX
>records you are implicitly talking about SMTP.  AFAIK the only
>protocol that takes advantage of MX records is SMTP.
>
>  
>
Joesph is correct, in that the only protocol that uses MX records is 
SMTP, after all they are Mail eXchanger records, and SMTP is for 
exchanging mail between two hosts.  :)  So, there are really two or 
three aspects to your mail system that you need to consider, and it's 
best if you understand the separation of them clearly.  Often in a small 
system they reside on the same machine -- and there's nothing wrong with 
that, but understanding the separation is key.  Forgive me if I digress 
too far, but better to far than not far enough.

First, mail comes in the front door.  It's received by an MTA.  Classic 
examples of MTAs are Sendmail, Postfix, and QMail.  This mail is then 
handed off (via a local delivery agent) to a mail store.  The mail store 
is usually dictated by how that mail will be accessed by the client, 
which brings us to our next part.  The client access methods are 
traditionally POP or IMAP.  There are various POP3 and IMAP4 servers, 
such as UW-IMAP, Courier, Cyrus, and Dovecot.  This "section" of the 
picture is entirely interchangeable with the MTA, and you may use what 
ever is most convenient, or you are most comfortable with.  There is one 
more section, which I like to think of separately, and that's web mail 
access.  Most modern webmail program use IMAP to access the mail store, 
so they really are interchangeable with any of the other IMAP servers 
mentioned here.  In some proprietary setups, the webmail client will 
actually be accessing the mail store directly (a terribly travesty), 
which means you can not easily change mail stores, and potentially could 
be locked into a IMAP / POP server as well, because of that mail store.

So now that you understand that a mail system is comprised of 3 distinct 
parts (MTA, Client-access Server, and possibly Webmail), you can begin 
to realize that scalability can happen in various places.  The simplest 
place to scale is at the MTA level.  You can very easily plunk down a 
secondary MX, which (should the primary MX become unavailable) receives 
and queues mail to be delivered to the primary MX when it becomes 
available again.  This is a cheap and easy way to guarantee that no 
incoming mail will be lost, should you experience down time on your 
server, or it's Internet connection (don't forget to locate that 
secondary MX on another pipe to the net, if possible).

The next easiest place to scale your mail solution is webmail.  If you 
in crease the number of servers, with traditional www load balancing 
techniques, you can easily scale the webmail solution.  Adding 
redundancy is just as easy.

The trickiest part is to scale the mail store.  Because you want to have 
a central place where all the mail is stored, I generally suggest a 
single box for this task, until you scale up to the university level or 
beyond.  You really can do fine with a single box doing IMAP / POP3 for 
all of your clients, well into the thousands of users.  Once you cross 
into a few tens of thousands of users, things get messy.  I don't think 
you're going to get that far given your situation, but for informational 
purposes, my suggestion would be to use a "Murder" or Cyrus IMAP 
servers.  There's a lot of documentation out there about it, and it's a 
terribly complicated solution, but I think it's the best way to go.  
Cyrus simply doesn't deal well with locking over NFS, so a single NFS 
share of all of the directories is out.  And unless you want to 
configure different clients different ways (ie. your mail server is 
a.mail.example.com because your username starts with an a), then you 
have to have some middle-man director system - that's where Cyrus excels.

So now that we've beat the mail-scalability horse to death - let me 
throw in my suggestion.  I personally use Postfix, with a (soon to be) 
Cyrus backend, which is 100% reliable, very easy to manage, and 
relatively simple to setup.  And that's with a system servicing 
thousands of users.  If you're comfortable with Qmail, then stick with 
it.  It's certainly serviceable, and it sounds like you've set it up w/ 
proper spam and virus scanning before.

Aaron S. Joyner



More information about the TriLUG mailing list