On 4/6/20 3:59 PM, Grant Taylor wrote: > · It's not five seconds a year. > · It's more likely an hour or two a year, possibly aggregated. > · You can't control the retry time frame on the sending side. > · You can control the retry / forward time on secondary MX(s). > · Messages can be canceled while sitting in sending systems queues. > · It's much more difficult for someone to interfere with messages > sitting on your systems. > · Especially without your knowledge. > · It's /still/ considered best practice to have /multiple/ inbound MX > servers. > · Be it primary / secondary > · Anycasted instance > · Other tricks > · Do you want to tell the CEO that he can't have his email for 36 > hours because you patched the mail server and the sender's system won't > retry for 35.5 hours? > > My professional and personal opinion is that if you're serious about > email, then you should have multiple inbound MX servers. >
The same RFC suggests how long the sending system should wait to retry: 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, RFC 1985 [36]. If someone decides to configure his mail server to retry only after a week, then sure, there's not much you can do about it. But it's not really fair for you to cherry-pick this one specific way that a sender can ignore the RFC, and claim that because a sender can ignore the RFC in this way, that it's better to adopt a different architecture that relies on the sender following the RFC in *another* very specific way (trying the backup MX sooner than they would retry the primary MX). Why aren't we pretending the sender will ignore that part of the RFC instead? The real-life manifestations of these problems are non-existent. Anyone who reads this thread and still decides to maintain a second MX to mitigate these purely-hypothetical issues does so only at the risk of his own free time and money. Caveat emptor =)
