Joseph Tate wrote:
On Fri, 5 Nov 2004 09:38:17 -0500, Ryan LeathersJoesph 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.
<[EMAIL PROTECTED]> 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.
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 -- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
