Backup MX or no?
-
@aaronstuder It's dumb, I know.
-
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.
-
@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.
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.
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.
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.
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.
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.
-
@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.
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?
-
@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.
-
@scottalanmiller said
"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.
So, to ensure delivered mail, a BackupMX type service is the way to go?
Trying to swing this back to the original topic/discussion.
-
@BRRABill said in Backup MX or no?:
@scottalanmiller said
"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.
So, to ensure delivered mail, a BackupMX type service is the way to go?
Trying to swing this back to the original topic/discussion.
If your goal is to always receive emails sent to you, yes, you need to keep your services up one way or another. 99% of the time, MTAs will resend for an hour, day, week or whatever. But that's not on your side so you have no control over that behaviour and more and more often people want the retry period shortened because they want to know that you are down and not receiving email pretty much instantly... not a week down the line when it finally times out and they've been wondering why you were not responding.
As there is little expectation that people will leave email down for any length of time and as people expect email to be more and more used and responded to, longer outages become less and less tolerated.
-
Well, I don't think you'd ever lose mail, but like @scottalanmiller said, it's not within your control. What should happen is once the sending MTA reaches it's retry limit, it should bounce the message back to the originating account.
-
@anthonyh said in Backup MX or no?:
Well, I don't think you'd ever lose mail, but like @scottalanmiller said, it's not within your control. What should happen is once the sending MTA reaches it's retry limit, it should bounce the message back to the originating account.
Right, at some point the sender (or the sending server at least) will get a failure message. But that might be many days later. Or might be very soon. If it happens, the user generally assumes you are gone totally.
