Using a toaster as a backup mailserver

[twa]

A backup mailserver will receive mail for your domain(s) in case the primary mailserver can't accept mail for some reason.


Scenario:

The host mail.example.com handles mail for example.com and acme-widgets.com. Hence, MX records for example.com and acme-widgets.com both point to mail.example.com and has a priority of 10.


If mail.example.com goes offline, we want mail to be sent to the server backup.example.com and stored there until mail.example.com comes back up.


Here's how you do it:

• Set up a toaster on a separate machine and place it as far away from the main server as possible. At the very minimum have it on a different subnet, preferrably in a different geographic location altogether. This machine is going to become backup.example.com. Spam and virus filters aren't strictly necessary on the backup MX, nor is webmail or any other end-user gadgetry. You don't need any mail accounts (apart from a test account) on the backup server either.
  
  
  
• In the DNS, add MX records with a priority of 20 to the domains example.com and acme-widgets.com. These MX records should point to the host backup.example.com. The idea is that anyone trying to send mail to example.com or acme-widgets.com will try the MX with a lower priority if the highest priority server is unavailable.
  
  
  
• On the host backup.example.com, edit /var/qmail/control/rcpthosts and add the following lines to it:
  
  
  Code Select Expand
  
example.com
acme-widgets.com

  
  
  The host backup.example.com will now accept mail for the two listed domains. Add more domains as you see fit.
  
  
  
• On backup.example.com, edit /var/qmail/control/smtproutes and add the following lines to it:
  
  
  Code Select Expand
  example.com:mail.example.com
acme-widgets.com:mail.example.com

  
  Add more domains as you see fit. The idea here is that the backup toaster will accept mail for these two domains and try to forward them to mail.example.com. If mail.example.com isn't up yet, the normal qmail retry cycle will handle the retries. This step isn't strictly necessary since qmail will try the "real" mail server automatically when retrying delivery.
  
  Notes:
  
  
  
• Try not to use IP-addresses or CNAMEs in MX records, even if it's possible. Doing this will upset quite a few RFC purists out there who in turn may reject mails coming from you.
  
  
• Depending on where you put your backup MX, test that mail from backup.example.com actually goes through virus and spam filters on mail.example.com.
  
  
• If you place your backup server in your own house on a DSL line, check that your DSL IP-address isn't listed in the RBLs you use. Whitelist the DSL IP-address (or dyndns domain or whatever) on your main server in that case. Be aware that some ISPs are blocking port 25 for home users.
  
  
• Make sure mail.example.com (your main mailserver) can handle the load when it comes back up again. You don't want to go right back offline because you were smart enough to add a backup MX 
  
  
• Document what you did and have some kind of contingency plan if the main server never comes back up.
  

[davidcl]

More good information, thanks.

The smtproutes entry is not necessary if your DNS is set up correctly.  I'd generally recommend against putting it there, because it's duplication of information that could end up causing confusion in certain situations.

For example, if the name of the primary server changes, and you update it in DNS, but you forget to update the smtproutes entry, it might be a while before you found the problem.

I generally use smtproutes in only two situations:

1) The customer's mail is destined for an "internal" mail server, but that server's name is not published to the outside world as an MX record in DNS.

2) My mail server is listed in my DNS server as an MX for the domain, but the end user has not yet changed their DNS to "go live" with my service.  Then I use smtproutes so that I can send email to the customer's old mail server.  (This commonly comes up when moving complex sites from another hosting company).

[johannes]

I have used this information to set up a backup mail server using qmail. The MX is higher (50) than of the primary MX (10).

Our client will unplug his mail server (the primary MX) for quite a long time, uncertain how long, but it could be weeks. Meanwhile, I want the backup server to store all incoming email. Eventually, the client's mail server will come up again, and all the email from the backup server will get delivered to it.

My questions:
1. Is there any limit for how long qmail will store the email, and try to deliver to the primary mail server?
2. And, will there be any "Sorry, I could not deliver..." messages sent from qmail?

I want this to be transparent to the mail senders, so that they do not notice that mail has not yet reached the primary server...

Any tips on how to do this? Thanks,
/ Johannes

[davidcl]

/var/qmail/control/queuelifetime

Number of seconds a message  can  stay  in  the  queue.   Default: 604800  (one  week).  After this time expires, qmail-send will try the message once more, but it will treat  any  temporary  delivery failures as permanent failures.

If the primary MX will be down for several weeks, you want to increase this number to be greater than the expected downtime.  

For example, 3024000 would be five weeks.

qmail does not send anything to the sender until the messages reach this age, then it sends a "permanent" bounce.

I think you have to restart qmail-send after you create/change this file.

[Nick Cockinos]

I've also used this technique to serve as a mail-gateway.

Basically, MX 10 the mail-gateway and MX 20 the destination mail server. Works great in our situation. We have an Exchange box and another two toasters. The Mail-Gateway checks in coming mail and sends it to the destination server(s)

[noratx]

I have just used this guide to get me a backup mailserver...  but how do I know that it works?