From SME Server
Jump to navigationJump to search


Category you want

Tags Filethiswithalistoftags


John Crisp


Alpha 10:
Alpha 9:
The latest version of smeserver-mxbackup is available in the SME repository, click on the version number(s) for more information.


Based on the original contrib. The following is copied from the web page here and pasted almost verbatim. It may want further review and amendments.

What is a MX Backup

Mails flow through Internet via a dedicated protocol : SMTP for Simple Mail Transport Protocol. This protocol, as stated in it name, is 'fairly' simple. When you send a mail, the first SMTP server start to analyse the recipient e-Mail. Look at this E-Mail : The part john.smith - part at left of the @ sign - is of no interest for the sender server : Comparing with 'snail mail', this is the Postal Box of Mister John Smith. This part will be used only by the destination SMTP server.

In contrary, the right part of the E-Mail, is of great interest : Still comparing to snail mail this is the final Post Office address.

In fact, this part of the address is a name, generally speaking a domain name. the SMTP server must now find the valid(s) SMTP server(s) for the domain It does this by asking it's DNS server.

In literal English, the SMTP Server ask it's DNS Server : "Could you please tell me witch are the SMTP servers for the domain ? " And the DNS Server give a list of servers name, with one more information : the priority order of the SMTP recipients.

Theses informations are stored in specifics entry of the DNS, named MX record (for Mail eXchanger)

You can check this kind of informations for instance so :

host -t mx mail is handled by 20 mail is handled by 10

Now, the sender SMTP server knows witch servers could accept the mails. It then try to send to the server with the lowest priority, also known as 'Primary MX server' or 'Primary SMTP server'.

But sometime, this Primary MX Server cannot be reached. This is why we can put more than one server for one domain. The primary server (generally, the server hosting the mailbox) One or more secondary servers (or MX-Backup servers). Theses servers retrieve incoming mail for the domain, and store them in they local outbound mail queue. And, on a cyclic basis, theses servers try to deliver the whole mail still in the outbound mail queue. The next time the primary server is reachable, the MX Backup server will deliver the pending mails. Note: today, many 'big' domain have more than one 'primary server'. In this case, the connection is made on a ramdom basis. This permits a distributed load, and a better scalability.

Configuration of a MX-Backup ?

We have to set two parts :

DNS Configuration : This is one of the key part of the work. You have to set-up properly your MX Records. One low priority for the primary SMTP server, another higher priority (normally the same) for the MX-Backup server.

MX Backup Server Configuration

Once upon a time, before the start of SPAM, every SMTP server on the net was set-up by default to act as a MX-Backup Server. You had just to configure the DNS. Now, all SMTP server on the net are set-up to avoid mail relaying (MX-Backup is technically speaking a specific kind of mail relaying). So you need to specify on your MX-Backup server the list of domains you plan to backup. And that's all. You do not have to set the name of the primary server on your MX-Backup server. Your MX-Backup server does as every SMTP does to obtain this information : it asks it's DNS server ! What do we need to set-up a MX Backup ? Needless to say, you need another SMTP admin wanting to do this stuff with you :-)

This page was written with my favorite Linux Distro in Mind : SME Server. But, with some adjustments, this should work on any server using QMAIL as SMTP service, except for the third method, using a RPM very SME specific.

You need also :

A Unix server (SME, of course) with a mail service Up and Running. A Public domain Name and a public DNS Server allowing you to have MX record. Some small files, that you can download from here Some time to spend and... the Famous RTFM ! That's Ok, you're just reading it ;-)


Starting from here, some assumptions for the whole samples : You are working with another admin on another domain, and you plan to be MX-Backup one for the other.

You are the admin from the mail server hosting the domain the name of your mail server is One of your e-mail is The second Admin is the admin from the mail server hosting the domain the name his your mail server is One of his e-mail is

yum --enablerepo=smecontribs install smeserver-mxbackup

Now, in the Configuration group, you have a MX Backup Configuration option just under E-Mail. Configuration is easy : Just click on the 'Create a new MX-Backup rule' button to add a domain name. Apart the name of the domain, you can select between 'HOST' and 'DOMAIN'.

The 'DOMAIN' choice is the general choice. It means that you accept mail not only in form but also mail in form The 'HOST' choice is the most paranoid : in this case, only mail in form are accepted, and mail in form are rejected. in this case, you could maybe need a few more rules for each host in each domain. That's all ! your SME server is ready to be a MX-Backup. You have also the possibility to disable and enable the MX-Backup functionality. Just click on the toggle button 'Disable MX-Backup' / 'Enable MX-Backup'. I hope you like my traffic lights !

Test and Validation Now, the rest of the page is the same for everybody ! Every SME version, and also QMAIL admin. In fact, you can use this test for every kind of MX Backup Server.

We now want to be sure that our MX Backup configuration is up and running. To do this test, we only need a computer everywhere on Internet with a telnet client. But this computer cannot be on our site, because Mail rules are different on the local server and the local network.

The easiest way is to ask the admin to do the work.

Testing is the longest part of the work. The tester will have to connect with Telnet on your SME mail Service. He will have to send every command like a real SMTP server 'send' an E-Mail.

But, quick, a very short review of the needed part of the SMTP protocol :

At the beginning of the session, the SMTP sender says who it is : This is the HELO command.

Then, The SMTP sender send information needed by the SMTP receiver. You can see that like the envelope for a mail : something the receiver never look, but very useful for the postman !. In E-Mail, you almost never see this part : you have to ask for the 'Header' of the mail to see that. But there are tons of useful informations for debugging : One interesting tip is that every SMTP server that carries the mail put a 'stamp' on the envelop. so you can see how your mail travelled.

In our very simple test mail, our envelop only contains 2 lines : MAIL From: {Sender E-mail address} RCPT To: {Recipient E-Mail Address}

Now it's time to start the letter content. To do that, we send the DATA command (alone on a line). Here, we could put anything. But, if you want that your mail has a good look in a normal mail reader, we have to put some 'valuables' informations, like the sender, the receiver, the subject or the date.

Here is a complete sample :

telnet 25
Connected to
Escape character is '^]'.
220 mailfront ESMTP
MAIL From:
250 Sender accepted.
250 Recipient accepted.
354 End your message with a period.
Date: Tue, Mar 09 2004, 21:00:00
Subject: Test

This test is very famous !

221 Good bye.
Connection closed by foreign host.

And here is the complete message (with header) that was received by John Smith

Return-Path: <>
Received: (qmail 24095 invoked by alias); 9 Mar 2004 21:36:17 -0000
Received: (qmail 24092 invoked from network); 9 Mar 2004 21:36:16 -0000
Received: from (HELO (
 by ( with SMTP; 09 Mar 2004 21:36:16 -0000
Received: (qmail 27033 invoked from network); 9 Mar 2004 21:27:51 -0000
Received: from (HELO (
 by ( with SMTP; 09 Mar 2004 21:27:51 -0000
Date: Tue, Mar 09 2004, 21:00:00
Subject: Test

This test is very famous ! That's OK, you did the minimum check : a Mail send for the domain is accepted by the mail server, and is able to forward it to You should also do the counter-test : check that your MX-Backup computer still refuse mail for another domain (i.e. that your MX-Backup is not a Open Relay ! ) :

telnet 25
Connected to
Escape character is '^]'.
220 mailfront ESMTP
MAIL From:
250 Sender accepted.
553 Sorry, that domain isn't in my list of allowed rcpthosts.
221 Good bye.
Connection closed by foreign host.
Enabling the configuration

Yes ! your MX-Backup system is ready ! Now, we have to tell the whole world that your mail can be processed also by your MX-Backup.

As admin, you have to change your internet DNS configuration. You need to add a second MX record for your domain with the name of your MX-Backup server, This mail server to have a priority greater than your primary MX server.

Remember, the DNS to change is your public DNS (often not on your site but somewhere else on Internet). Check the DNS configuration this way (You need the address of your primary public DNS server, to check the entry like Internet SMTP server will do) : Saying that the ip address of your primary public DNS is, check so :

host -t mx
Using domain server:
Aliases: mail is handled (pri=0) by mail is handled (pri=5) by

Great : Job done ! Just wait that DNS information are updated everywhere, and your MX-Backup is up and running.

Special case : the 'SmartHost'

I had an interesting field return about 'MX-Backup' The case of a SME server acting as MX-Backup, but using a SMTP 'SmartHost' to deliver mails.

What is a 'Smart Host' ?

In SMTP protocol, a server has two choices to send a mail : 'direct' mode: For each mail to delicver, the SMTP sender try to find the good destination server(s). This is done via a DNS search of MX records for the destination domain. After the DNS resolution, the SMTP sender try to connect directly to the designed destination SMTP servers, following normally the priority rules set in the DNS. 'Smart Host' Mode: The SMTP sender cannot or don't want to do direct SMTP connection : Poor DNS resolution, Firewall not allowing theses connections, poor SMTP implementation... In this case, the SMTP server send all outgoing mail to a wall known SMTP host, witch is able to do all the work : the 'Smart Host'. Nota: on SME, this choice is selected (in 'server-manager') by setting the IP address or the host name of the SMTP SmatHost in the 'E-Mail' Menu', choice : 'Address of Internet provider's mail server'. Problem : the MX-Backup mode cannot work with the 'SmartHost' Mode !

Why ?

Well, let's suppose that is the secondary MX for the domain And is set to use as 'SmartHost'. At some time, the primary MX server for the domain is out of order. Every new mail for the domain now arrive on the server. But is set to use as 'SmartHost', and mail for are to resend out. send happilly all mails for to in turn does a DNS resolution, and see that the mail should be delivered to !!!

This is called 'BounceMail' (and this is bad...). In the best case, your SME server will detect the bounce first. In the worst case, it's who will find the bounce first, and you should very fast learn some interesting thing about the mail Admin of

Starting with version 0.1.0 of MX-Backup, this is no more possible : During MX-Backup configuration, if the system is configured to use a 'SmartHost', MX-Backup set the configuration file to still use a direct access mode to the 'MX-Backuped domains'.

But this can be even worse ! Two majors reasons can dictate to choose to use the provider SMTP server as a 'SmartHost' : Because of troubles with recipients SMTP servers. Some SMTP servers no more allow SMTP connection from SMTP server without a valid reverse DNS entry (who need to be the same as the SME domain name). Others servers have 'blacklisted' majors ISP dynamics customers IP range. In this case, the new settings of MX-Backup will works as expected: Major outbound traffic via the SMTP SmartHost, and direct connection for 'MX-Backuped' domain. Your provider don't let you do direct connection on external IPs on port 25. (For instance, in France, télé 2 does that). In this case, your MX-Backup will still not work, but you cannot any more send mails to your MX-Backuped domains ! But if you're in the latter case, and if you plan to be MX-Backup for a SME server too, a solution exists. please drop me a mail, and I'll try to explain you that.

And after ?

Not a lot to add... Maybe do you want more than one MX Backup. That no problem. Just configure the second MX-Backup like the first, and add a third MX record in your public DNS.


you can list the available configuration with the following command :

config show smeserver-mxbackup

Some of the properties are not shown, but are defaulted in a template or a script. Here a more comprehensive list with default and expected values :

property default values comment
mxbackup service disabled
name Empty host/domain,index number
status enabled enabled,disabled


yum remove smeserver-mxbackup  


Please raise bugs under the SME-Contribs section in bugzilla

and select the smeserver-mxbackup component or use this link

Below is an overview of the current issues for this contrib:

IDProductVersionStatusSummary (2 tasks)
12162SME Contribs10.0CONFIRMEDFirst import to Koozali SME v10 [smeserver-mxbackup]
10182SME ContribsFuturIN_PROGRESSCompatibilty with SME 9 and/or 10


Only released version in smecontrib are listed here.