Mxbackup
 | |
| logo | |
| Maintainer | maintainer |
|---|---|
| Url | https://wiki.koozali.org |
| Category | |
| Tags | File, this, with, a, list, of, tags |
Maintainer
Version
Description
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 :
john.smith@smithnet.com 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, smithnet.com 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 smithnet.com. 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 smithnet.com ? " 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 cw.com
cw.com mail is handled by 20 mail14.messagelabs.com. cw.com mail is handled by 10 mail49.messagelabs.com.
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 ;-)
Installation
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 doecom.net the name of your mail server is mail.doecom.net One of your e-mail is steve.doe@doecom.net The second Admin is the admin from the mail server hosting the domain smithnet.com the name his your mail server is mail.smithnet.com One of his e-mail is john.smith@smithnet.com
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 some_guy@smithnet.com but also mail in form some_guy@mail.smithnet.com. The 'HOST' choice is the most paranoid : in this case, only mail in form some_guy@smithnet.com are accepted, and mail in form some_guy@mail.smithnet.com 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 smithnet.com 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 mail.doecom.net 25
Trying 111.112.113.114... Connected to mail.doecom.net Escape character is '^]'. 220 sme.doecom.net mailfront ESMTP HELO anything.other.org 250 sme.doecom.net MAIL From: admin@anything.other.org 250 Sender accepted. RCPT To: john.smith@smithnet.com 250 Recipient accepted. DATA 354 End your message with a period. From: admin@anything.other.org To: john.smith@smithnet.com Date: Tue, Mar 09 2004, 21:00:00 Subject: Test
This test is very famous !
. 250 QUIT 221 Good bye. Connection closed by foreign host.
And here is the complete message (with header) that was received by John Smith
Return-Path: <admin@anything.other.org> Delivered-To: john@server.smithnet.com Received: (qmail 24095 invoked by alias); 9 Mar 2004 21:36:17 -0000 Delivered-To: alias-localdelivery-john@smithnet.com Received: (qmail 24092 invoked from network); 9 Mar 2004 21:36:16 -0000 Received: from mail.doecom.net (HELO doecom.net) (111.112.113.114) by mail.smithnet.com (100.99.98.97) with SMTP; 09 Mar 2004 21:36:16 -0000 Received: (qmail 27033 invoked from network); 9 Mar 2004 21:27:51 -0000 Received: from some.other.computer.on.the.net (HELO anything.other.org) (200.200.200.200) by sme.doecom.net (111.112.113.114) with SMTP; 09 Mar 2004 21:27:51 -0000 From: admin@anything.other.org To: john.smith@smithnet.com 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 smithnet.com is accepted by the mail server mail.doecom.net, and mail.doecom.net is able to forward it to mail.smithnet.com 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 mail.doecom.net 25
Trying 111.112.113.114... Connected to mail.doecom.net. Escape character is '^]'. 220 sme.doecom.net mailfront ESMTP HELO anything.other.org 250 smedoecom.net MAIL From: a_guy@anything.other.org 250 Sender accepted. RCPT To: tomy@hotmail.com 553 Sorry, that domain isn't in my list of allowed rcpthosts. QUIT 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 smithnet.com 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, mail.doecom.net. 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 1.2.3.4, check so :
host -t mx smithnet.com 1.2.3.4
Using domain server: Name: 1.2.3.4 Address: 1.2.3.4#53 Aliases:
smithnet.com mail is handled (pri=0) by mail.smithnet.com smithnet.com mail is handled (pri=5) by mail.doecom.net
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 mail.bar.foo is the secondary MX for the domain strangers.here. And mail.bar.foo is set to use smtp.provider.net as 'SmartHost'. At some time, the primary MX server for the domain strangers.here is out of order. Every new mail for the domain strangers.here now arrive on the mail.bar.foo server. But mail.bar.foo is set to use smtp.provider.net as 'SmartHost', and mail for strangers.here are to resend out. mail.bar.foo send happilly all mails for strangers.here to smtp.provider.net. smtp.provider.net in turn does a DNS resolution, and see that the mail should be delivered to mail.bar.foo !!!
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 smtp.provider.net who will find the bounce first, and you should very fast learn some interesting thing about the mail Admin of smtp.provider.net...
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.
Configuration
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 |
Uninstall
yum remove smeserver-mxbackup
Bugs
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:
| ID | Product | Version | Status | Summary (2 tasks) ⇒ |
|---|---|---|---|---|
| 12162 | SME Contribs | 10.0 | CONFIRMED | First import to Koozali SME v10 [smeserver-mxbackup] |
| 10182 | SME Contribs | Futur | IN_PROGRESS | Compatibilty with SME 9 and/or 10 |
Changelog
Only released version in smecontrib are listed here.