I got a rule in place that should cover this. I'll monitor and make sure the desired behavior is occurring.
On Wed, Jun 21, 2023, 7:27 PM Michael Orlitzky <mich...@orlitzky.com> wrote: > On 2023-06-21 18:39:59, Luke wrote: > > Ahh. Thats funny. Apologies. You'll have to refresh my memory. > > > > Happy to help if I can. Give me the full response, code and string, and > > tell me how you'd like us to handle it and if it makes sense, I can make > > the necessary changes. > > > > In this case, before patching, the original response was, > > 450 4.3.2 Service currently unavailable > > After patching, it's > > 450 4.3.2 Please retry immediately > > I'd rather not patch our MTA for the rest of eternity, so a rule for > the first response would be preferable. But if that's not possible I > can live with the second. After all, that was my hope/plan after the > last discussion. > > In either case, one quick retry (a minute?) followed by a few slower > attempts (1h, 12h, 24h, etc.) for 4-5 days would be perfect. The > quicker retries help with the planned hiccups, while the longer ones > accomodate the unplanned ones. > > However, a custom rule would address only that one source of 4xx > error. Others are popular. For example, > > 450 4.3.0 Queue file write error > > when we kill a filter process while the MTA is waiting on it. And > that's just for our MTA. > > I think I've already disproven the null hypothesis, that SendGrid > retries normally in the absense of statistical evidence discouraging > it. If that's not the case, it should be: the default should be to do > the right thing and retry. Otherwise, everyone is going to have to hack > their MTAs to return some magic phrase. > > Still, I'll take what I can get. Thanks for responding again. >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
