Backup MX or no?



  • I'm going to be doing some email maintenance this weekend (moving Zimbra from Ubuntu to CentOS). I have a plan laid out and things should go smoothly, but we will still be down for a while. My plan of attack is so:

    • Block mail related ports on existing server so no new mail comes in.
    • Perform incremental backup of all mailboxes
    • Restore backup to new server (this will take a while)
    • Re-IP new server to match old
    • Test send/receipt of mail
    • If all is good, $profit

    I suspect between the incremental backup and subsequent restore to the new server will take 4 or so hours. Add in 2 hours buffer for accommodating "unknowns" that come up (there is always a mailbox or two that fail to restore for some reason).

    Do you think it would be worth setting up a backup MX to receive mail while we are down? Or is relying on the sending mail servers to retry/bounce if TTL is reached good enough?

    I suppose there is equal risk of losing mail due to error on my part in configuring a backup MX (I've never done it before) as there is with mail servers that don't properly handle undeliverable messages. Also, I'd need to deal with spam on the backup MX too.

    Thoughts?



  • It's very cheap... I would.

    If I was hosting email on-site I mean 😉


  • Service Provider

    It's very easy to do, the only question is, how much mail do you need to clean before you release it onto your server? i.e spam.

    If you have 20 or so users, it might not be so bad to skim through and delete the obvious ones.

    If you have 200 users, well that becomes a job.



  • @Breffni-Potter said in Backup MX or no?:

    It's very easy to do, the only question is, how much mail do you need to clean before you release it onto your server? i.e spam.

    If you have 20 or so users, it might not be so bad to skim through and delete the obvious ones.

    If you have 200 users, well that becomes a job.

    We have 400 mail accounts. So this gives me pause. Though, in theory, wouldn't my mail server handle the incoming messages from the backup MX as it would anything else?

    Also, I'd need to set this up in-house. I'd love to jump on a cloud based service for this, but we're not there yet.



  • I use Backup MX from No-IP. It's a little cheaper than the other one mentioned. It just spools your mail any time it is down.

    If you host onsite it's a good service to have 24/7/365 anyway.

    http://www.noip.com/managed-mail#self-hosted



  • Regardless of this project, if your going to host email on site, you should have a backup MX provider.

    What do you do when the server fails, or you misconfigure something? Just lose mail? That seems like a bad plan.



  • @aaronstuder said in Backup MX or no?:

    Regardless of this project, if your going to host email on site, you should have a backup MX provider.

    What do you do when the server fails, or you misconfigure something? Just lose mail? That seems like a bad plan.

    Yeah ours has saved our bacon numerous times.



  • @aaronstuder said in Backup MX or no?:

    Regardless of this project, if your going to host email on site, you should have a backup MX provider.

    What do you do when the server fails, or you misconfigure something? Just lose mail? That seems like a bad plan.

    Depending on how something is misconfigured, you can still lose mail. I haven't experienced it personally, but I've heard of scenarios where a mail server was "accepting" mail, but the mail was lost. shrug

    We've had a couple of outages before and just dealt with it. One was a mail server outage (it ran out of disk space the first week I was here), the other was an ISP outage. It's never been a big deal really. We let our users know what to expect when events occur.

    Just trying to reach a good KISS balance. If a backup MX makes sense (which it's sounding like it might), then I'll do it. 🙂



  • @anthonyh $30 a year seems like a no brainer to me. I can help you with DNS records if you need it.



  • @anthonyh said

    Depending on how something is misconfigured, you can still lose mail. I haven't experienced it personally, but I've heard of scenarios where a mail server was "accepting" mail, but the mail was lost. shrug

    We've had a couple of outages before and just dealt with it. One was a mail server outage (it ran out of disk space the first week I was here), the other was an ISP outage. It's never been a big deal really. We let our users know what to expect when events occur.

    I've had that happen, where our server ran out of disk space, but the server never stopped accepting e-mail.

    I have since changed some settings, but it's definitely something I have seen. What happens to us much more frequently is an Internet outage.



  • @aaronstuder said in Backup MX or no?:

    @anthonyh $30 a year seems like a no brainer to me. I can help you with DNS records if you need it.

    DNS is a non-issue. I'd just need to host whatever does backup MX for us on-site or invest in a AWS or Azure VM of some sort that I can control. For this purpose though something on-site would be fine.



  • @anthonyh I think your confused... The backup MX service is already hosted... They just forward emails along to your server, unless your server is down then they store them.



  • @aaronstuder said in Backup MX or no?:

    @anthonyh I think your confused... The backup MX service is already hosted... They just forward emails along to your server, unless your server is down then they store them.

    No, I'm not confused.

    I understand that this only comes into play with our primary MX is down (or if a non-compliant SMTP server sends to our backup MX).

    It's a matter of trust. Yes, they'll forward our mail to us when we're back up, but we have no control of what else they do with said data. It's a control issue.



  • @anthonyh Ohhhhh. I see.



  • @aaronstuder It's dumb, I know. 😃


  • Service Provider

    Any reason you don't have an existing service for this? With in house email I would typically still have a service for this "out front". You could implement that now and problem solved.



  • @scottalanmiller said in Backup MX or no?:

    Any reason you don't have an existing service for this? With in house email I would typically still have a service for this "out front". You could implement that now and problem solved.

    Nobody has ever thought it was a need. It hasn't really been an issue.



  • This article was written around a specific mail platform, and is roughly 4 years old, but I'm curious on y'all's opinion. It's an argument against a secondary/backup MX.

    https://blog.zensoftware.co.uk/2012/07/02/why-we-tend-to-recommend-not-having-a-secondary-mx-these-days/



  • @anthonyh said in Backup MX or no?:

    This article was written around a specific mail platform, and is roughly 4 years old, but I'm curious on y'all's opinion. It's an argument against a secondary/backup MX.

    https://blog.zensoftware.co.uk/2012/07/02/why-we-tend-to-recommend-not-having-a-secondary-mx-these-days/

    It brings up an interesting question that hopefully someone here can answer.

    What does happen to a piece of e-mail that is sent when your server is down? Does it really go back to the sending server, and queue up to be retried?



  • @BRRABill said in Backup MX or no?:

    @anthonyh said in Backup MX or no?:

    This article was written around a specific mail platform, and is roughly 4 years old, but I'm curious on y'all's opinion. It's an argument against a secondary/backup MX.

    https://blog.zensoftware.co.uk/2012/07/02/why-we-tend-to-recommend-not-having-a-secondary-mx-these-days/

    It brings up an interesting question that hopefully someone here can answer.

    What does happen to a piece of e-mail that is sent when your server is down? Does it really go back to the sending server, and queue up to be retried?

    I'm no expert, but my understanding is that SMTP was written with the idea that the Internet is not reliable. Therefore, RFC compliant SMTP servers should queue messages and periodically re-try sending for a period of time.

    There is a bunch of info here (thanks, Google!): https://www.ietf.org/rfc/rfc2821.txt



  • My spam filter provides spooling if my mail/internet goes down at the local site.



  • From the link I posted (https://www.ietf.org/rfc/rfc2821.txt). Of course, it's all "should", so it's dependent on how the sending server is configured.

    4.5.4.1 Sending Strategy

    The general model for an SMTP client is one or more processes that
    periodically attempt to transmit outgoing mail. In a typical system,
    the program that composes a message has some method for requesting
    immediate attention for a new piece of outgoing mail, while mail that
    cannot be transmitted immediately MUST be queued and periodically
    retried by the sender. A mail queue entry will include not only the
    message itself but also the envelope information.

    The sender MUST delay retrying a particular destination after one
    attempt has failed. In general, the retry interval SHOULD be at
    least 30 minutes; however, more sophisticated and variable strategies
    will be beneficial when the SMTP client can determine the reason for
    non-delivery.

    Retries continue until the message is transmitted or the sender gives
    up; the give-up time generally needs to be at least 4-5 days. The
    parameters to the retry algorithm MUST be configurable.

    A client SHOULD keep a list of hosts it cannot reach and
    corresponding connection timeouts, rather than just retrying queued
    mail items.

    Experience suggests that failures are typically transient (the target
    system or its connection has crashed), favoring a policy of two
    connection attempts in the first hour the message is in the queue,
    and then backing off to one every two or three hours.

    The SMTP client can shorten the queuing delay in cooperation with the
    SMTP server. For example, if mail is received from a particular
    address, it is likely that mail queued for that host can now be sent.
    Application of this principle may, in many cases, eliminate the
    requirement for an explicit "send queues now" function such as ETRN
    [9].

    The strategy may be further modified as a result of multiple
    addresses per host (see below) to optimize delivery time vs. resource
    usage.



  • Understood, but I wonder what reality is.



  • @BRRABill said in Backup MX or no?:

    Understood, but I wonder what reality is.

    In my experience it has been good, but I really don't have a scientific way of evaluating this. From what I understand, Postfix is configured to 5 days by default.



  • @anthonyh said in Backup MX or no?:

    This article was written around a specific mail platform, and is roughly 4 years old, but I'm curious on y'all's opinion. It's an argument against a secondary/backup MX.

    https://blog.zensoftware.co.uk/2012/07/02/why-we-tend-to-recommend-not-having-a-secondary-mx-these-days/

    When I read this, I don't read don't have more then 1 server, I read don't have more then 1 MX record. Am I wrong?

    It's seems they are saying, making your backup MX provider your MX record, and then let them forward to you. Am I missing something here? I know you can have 2 MX records, but I thought have just 1 was more common, then letting the backup provider forward to you.



  • @aaronstuder said in Backup MX or no?:

    @anthonyh said in Backup MX or no?:

    This article was written around a specific mail platform, and is roughly 4 years old, but I'm curious on y'all's opinion. It's an argument against a secondary/backup MX.

    https://blog.zensoftware.co.uk/2012/07/02/why-we-tend-to-recommend-not-having-a-secondary-mx-these-days/

    When I read this, I don't read don't have more then 1 server, I read don't have more then 1 MX record. Am I wrong?

    It's seems they are saying, making your backup MX provider your MX record, and then let them forward to you. Am I missing something here? I know you can have 2 MX records, but I thought have just 1 was more common, then letting the backup provider forward to you.

    I don't think so. That would be the better solution though. You'd have a predictable path "mail always comes from X" and wouldn't need to futz with spam rules and whatnot.



  • @aaronstuder said in Backup MX or no?:

    @anthonyh said in Backup MX or no?:

    This article was written around a specific mail platform, and is roughly 4 years old, but I'm curious on y'all's opinion. It's an argument against a secondary/backup MX.

    https://blog.zensoftware.co.uk/2012/07/02/why-we-tend-to-recommend-not-having-a-secondary-mx-these-days/

    When I read this, I don't read don't have more then 1 server, I read don't have more then 1 MX record. Am I wrong?

    It's seems they are saying, making your backup MX provider your MX record, and then let them forward to you. Am I missing something here? I know you can have 2 MX records, but I thought have just 1 was more common, then letting the backup provider forward to you.

    I don't have what I consider a backup provider. I use Appriver to receive all email. We have one MX record and it points to them. They have a highly reliable/resilient system, perhaps redundant too. They receive all of my email, clean it, then pass it along to me. If my server is down, they queue it up until my server comes back online. The people sending me email never know that it wasn't delivered immediately.


  • Service Provider

    @anthonyh said in Backup MX or no?:

    @BRRABill said in Backup MX or no?:

    @anthonyh said in Backup MX or no?:

    This article was written around a specific mail platform, and is roughly 4 years old, but I'm curious on y'all's opinion. It's an argument against a secondary/backup MX.

    https://blog.zensoftware.co.uk/2012/07/02/why-we-tend-to-recommend-not-having-a-secondary-mx-these-days/

    It brings up an interesting question that hopefully someone here can answer.

    What does happen to a piece of e-mail that is sent when your server is down? Does it really go back to the sending server, and queue up to be retried?

    I'm no expert, but my understanding is that SMTP was written with the idea that the Internet is not reliable. Therefore, RFC compliant SMTP servers should queue messages and periodically re-try sending for a period of time.

    There is a bunch of info here (thanks, Google!): https://www.ietf.org/rfc/rfc2821.txt

    that's correct, that's why email used to routinely take 48 hours to reach people, back when I was first using it. When servers were on dial up it made it take forever to relay from machine to machine.



  • @scottalanmiller said

    that's correct, that's why email used to routinely take 48 hours to reach people, back when I was first using it. When servers were on dial up it made it take forever to relay from machine to machine.

    I think that's why I originally started using the BackupMX product. Once the server came back up, it seemed like it took forever for the mail to start filtering back in.

    So, the thinking is that is I did not have the spooling MX server, I should not miss any mail?


  • Service Provider

    @BRRABill said in Backup MX or no?:

    So, the thinking is that is I did not have the spooling MX server, I should not miss any mail?

    "Should" is not applicable. "Might" is the answer. It is purely up to the company sending the mail on to you, the sending MTA, as to how it will interpret your outage.