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
