(Printer-friendly display)

Migrating from Microsoft Exchange to qmail

The Phased Approach

Preparing to install qmail

The preparation stage is the most appropriate time to get answers. The more you know about qmail before proceeding to the next step, the higher your chances of succeeding the first time.

Thinking back, I would have bought a copy of The qmail Handbook before I started. The book contains much of the same information as LWQ, but there's a greater level of detail about certain topics in the book. Readers should note however, that LWQ has been recently updated and may provide more up-to-date information.

Acquiring, Building and Configuring qmail

As we went through each step of the build process, we read carefully and checked off each item as we completed it. We learned that skipping the simplest command could easily result in a non-working qmail and finding the error was like looking for a needle in a haystack.

Phase 1: Basic qmail

1. We created /var/qmail/control/me with the fully qualified name of the qmail host:

   bellux.theotherbell.com

2. We created /var/qmail/control/rcpthosts with the fully qualified name of the qmail host:

   bellux.theotherbell.com

3. We verified that the smtproutes control file did not exist.
4. We created /var/qmail/control/defaultdelivery to use Maildir's:

   ./Maildir/

5. We created a new account (qmailtest) and used maildirmake to initialize the user's Maildir.
6. We added qmailtest to /var/qmail/users/assign and used qmail-newu to rebuild the user database.
7. We created dot-qmail files in /var/qmail/aliases for root, postmaster and mailer-daemon to force all mail for system accounts to be delivered to qmailtest. We also configured aliases for nobody and webmaster to handle email associated with our webserver. We added a single line to .qmail-root:

   qmailtest

   We created a symbolic link from .qmail-root to .qmail-postmaster, .qmail-mailer-daemon, .qmail-nobody and .qmail-webmaster.

8. We used qmail-showctl to review the configuration for accuracy.
9. Finally, we started qmail.

1. Used svstat /service/* to make sure qmail-send and qmail-smtpd were running
2. Used svstat /service/*/log to make sure multilog was running for both qmail-send and qmail-smtpd
3. Used telnet to verify that we could connect to qmail:

   $ telnet 0 25
   Trying 0.0.0.0...
   Connected to 0.
   Escape character is '^]'.
   220 bellux.theotherbell.com ESMTP
   ^]
   
   telnet> quit
   Connection closed.
   $

4. Used the command line to send a message to qmailtest:

   echo to: qmailtest | /var/qmail/bin/qmail-inject

   We verified that the message was delivered by looking in /home/qmailtest/Maildir/cur.

5. Set up an email account (test7891) at Hotmail and used the command line to send a message to the remote account:

   echo to: test7891@hotmail.com| /var/qmail/bin/qmail-inject

   We logged in to the Hotmail account to confirm the email was received.

Phase 2: qmail as an Exchange Front-End

The biggest issue we were concerned with in this step was how to configure qmail to accept email from external SMTP clients without affecting delivery to either Exchange users or user accounts on the qmail host. At the end of this step, we wanted all email for Exchange users to be relayed to the Exchange Server while all other email such as that generated by cron was delivered to the appropriate Maildir on the qmail host.

Since we only have a single public IP address, we decided to add a new CNAME entry for mail.theotherbell.com to our DNS configuration at ZoneEdit. This would allow external senders to address mail to some-user@theotherbell.com or some-other-user@mail.theotherbell.com. The email for theotherbell.com would be relayed to the Exchange Server while email for mail.theotherbell.com would be delivered to a Maildir on the qmail host.

1. We added two new entries to the rcpthosts control file: one for our Exchange domain (theotherbell.com) and another for our new CNAME. The file then contained three entries:

   bellux.theotherbell.com
   mail.theotherbell.com
   theotherbell.com
   

2. We created the smtproutes control file and added one line to forward all email for theotherbell.com to the Exchange Server:

   theotherbell.com:exchange.theotherbell.com

3. We created the locals control file and added two lines:

   bellux.theotherbell.com
   mail.theotherbell.com
   

4. We restarted qmail-send to make the changes take effect.

1. We configured a /var/qmail/alias/.qmail-default to route all email for unknown recipients to qmailtest:

   echo qmailtest > /var/qmail/alias/.qmail-default
   

2. We repeated the tests from Phase 1 to make sure everything was still working as before.
3. We used the command line to send email to a non-existent user to make sure it was received by qmailtest. As before, we verified the email was delivered by looking in /home/qmailtest/Maildir/cur.
4. We used the command line to send email to a valid Exchange user to make sure qmail was properly relaying email for theotherbell.com to the Exchange Server. We logged in to Exchange to make sure the email was received.

1. We reconfigured our firewall to pass all SMTP connections to the qmail host rather than the Exchange Server host.
2. We logged in to our Hotmail account and sent three emails: one to our qmailtest account (account@mail.theotherbell.com), another to an invalid user (bogus@mail.theotherbell.com) and a third to a valid Exchange user (user@theotherbell.com). We immediately started watching our logs looking for the point at which the emails were accepted for delivery.
3. As soon as we saw evidence that the emails had been received, we immediately restored the firewall configuration to pass all SMTP connections to the Exchange Server host.
4. We used our Hotmail account to send a fourth and final email to a valid Exchange user.
5. We first logged in to Exchange to make sure the fourth email was received. This served as evidence that our email service was functioning exactly as it was at the end of Phase 1; e.g., there was no longer a risk of losing email.
6. We then started the process of verifying the successful receipt and delivery of the first three emails, making sure they were delivered to the appropriate Maildir's and Exchange inbox.

1. We removed /var/qmail/alias/.qmail-default; from this point forward, we want to bounce all email for unknown recipients.
2. We reconfigured the aliases for the system accounts to route email to a valid Exchange user:

   admin@theotherbell.com
   

3. We reconfigured the firewall to re-establish qmail as an Exchange front-end.

Phase 3: qmail as an Exchange Replacement

1. We first installed, configured and tested Courier-IMAP using our qmailtest account, making sure we could connect and view email from each of our email client applications.
2. Since we have a small number of users, we then set up machine accounts for each Exchange user and used maildirmake to initialize each user's Maildir.
3. To support mailing lists and one-off email addresses -- addresses we could give out on the Internet and easily terminate if they started getting spammed -- we gave each user a real email address and two dash-extension addresses in /var/qmail/users/assign:

   =janedoe:janedoe:501:400:/home/janedoe:::
   +janedoe-:janedoe:501:400:/home/janedoe:-::
   +jd-list-:janedoe:501:400:/home/janedoe:-:list-:

4. For each of our mail-enabled Exchange folders, we either set up machine accounts or added a line to /var/qmail/users/assign to deliver email for the folder to an existing account.
5. We ran qmail-newu to rebuild the user database.
6. We then created three dot-qmail files in each user's home directory, one for each line in /var/qmail/users/assign:

   .qmail
   .qmail-default
   .qmail-list-default

   Each dot-qmail file contained a single line:

   ./Maildir/
   

7. We removed theotherbell.com from the smtproutes control file.
8. We added theotherbell.com to the locals control file.
9. We restarted qmail-send to make the changes take effect.

(Printer-friendly display)