Good Bye MX Backup

Finally, after so many years I have been using MX Backup, I changed the decision not to use MX Backup. It was a very difficult situation, because all of us like to have “Backup” system in all of our systems, don’t we ?? .

I took that decision because of some consideration as follows:

• Difficulties in maintaining MX Backup, especially for Security settings, Spam handling, etc. If we read the logs or the mail header, there are a lot of spam messages (also worm viruses) come through MX Backup, because most of the System Administrators pay more attention to the MX Primary, compared to MX Backup.
• With a single MX, we have virtually unlimited MX Backup. All MTA following Internet standard (RFC compliant) must retry to send non-fatal first attempt delivery. RFC also recommends that retrying process should be done within 5 days. Therefore, as long as our server or link to our server is not down within 5 consecutive days, not-delivered messages accident should be minimum.
• With single MX, the possibilities of thundering heart attack is minimized. Because all deferred messages are still in the sender’s mail server with their own mail delivery schedule, then when our server is up again, it will not have burst mail in huge volume within a short time period, but it will be evently spreaded in a longer time period which manageable by the server and not affecting server crash.
• With Single MX, the server will not have excessive burdens if the sender support Smartspooling or MX Piggy Backing, because the mail sent with smartspooling will be treated as a single session by the mail server.

Thanks to Mr Syafril Hermansyah on his generous explainations.