ML
    • Recent
    • Categories
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    Backup MX or no?

    IT Discussion
    7
    36
    6.2k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • BRRABillB
      BRRABill @Alex Sage
      last edited by

      @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.

      1 Reply Last reply Reply Quote 1
      • anthonyhA
        anthonyh @Alex Sage
        last edited by

        @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. 🙂

        A BRRABillB 2 Replies Last reply Reply Quote 0
        • A
          Alex Sage @anthonyh
          last edited by

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

          anthonyhA 1 Reply Last reply Reply Quote 0
          • BRRABillB
            BRRABill @anthonyh
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • anthonyhA
              anthonyh @Alex Sage
              last edited by anthonyh

              @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.

              A 1 Reply Last reply Reply Quote 0
              • A
                Alex Sage @anthonyh
                last edited by

                @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.

                anthonyhA 1 Reply Last reply Reply Quote 0
                • anthonyhA
                  anthonyh @Alex Sage
                  last edited by

                  @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.

                  A 1 Reply Last reply Reply Quote 0
                  • A
                    Alex Sage @anthonyh
                    last edited by

                    @anthonyh Ohhhhh. I see.

                    anthonyhA 1 Reply Last reply Reply Quote 0
                    • anthonyhA
                      anthonyh @Alex Sage
                      last edited by

                      @aaronstuder It's dumb, I know. 😄

                      1 Reply Last reply Reply Quote 0
                      • scottalanmillerS
                        scottalanmiller
                        last edited by

                        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.

                        anthonyhA 1 Reply Last reply Reply Quote 2
                        • anthonyhA
                          anthonyh @scottalanmiller
                          last edited by

                          @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.

                          1 Reply Last reply Reply Quote 0
                          • anthonyhA
                            anthonyh
                            last edited by anthonyh

                            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/

                            BRRABillB A 2 Replies Last reply Reply Quote 0
                            • BRRABillB
                              BRRABill @anthonyh
                              last edited by

                              @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?

                              anthonyhA 1 Reply Last reply Reply Quote 0
                              • anthonyhA
                                anthonyh @BRRABill
                                last edited by

                                @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

                                scottalanmillerS 1 Reply Last reply Reply Quote 2
                                • brianlittlejohnB
                                  brianlittlejohn
                                  last edited by

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

                                  1 Reply Last reply Reply Quote 1
                                  • anthonyhA
                                    anthonyh
                                    last edited by

                                    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.

                                    1 Reply Last reply Reply Quote 0
                                    • BRRABillB
                                      BRRABill
                                      last edited by

                                      Understood, but I wonder what reality is.

                                      anthonyhA 1 Reply Last reply Reply Quote 0
                                      • anthonyhA
                                        anthonyh @BRRABill
                                        last edited by

                                        @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.

                                        1 Reply Last reply Reply Quote 0
                                        • A
                                          Alex Sage @anthonyh
                                          last edited by Alex Sage

                                          @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.

                                          anthonyhA DashrenderD 2 Replies Last reply Reply Quote 0
                                          • anthonyhA
                                            anthonyh @Alex Sage
                                            last edited by

                                            @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.

                                            1 Reply Last reply Reply Quote 0
                                            • 1
                                            • 2
                                            • 1 / 2
                                            • First post
                                              Last post