The last time SendGrid's failure to retry 4xx came up here, their response was that, when determining whether or not to retry, they analyze not only the 4xx code but also the associated text. If (based on those data) a retry is statistically unlikely, they won't do it.
The RFC forbids doing that, and I argued against it -- not just on principle, but because when 99% of your mail is spam and 1% is not, grouping them together introduces a base-rate fallacy into your decision-making process. Regardless, it looks like I was wasting my time: their explanation is incomplete at best. Since then I've patched our mail server to reply with unique 4xx text. Retries to us will almost always succeed, so our unique (code,text) pairs, being unaffected by anyone else, should be associated with a high probability of success. Still, they choose not to retry. These are a pair of tickets for Hershey Park that a family has been waiting on for two days: # grep 'hersheypa\.com' /var/log/mail/mail.log* mail.log-20230620:Jun 20 09:25:53 mx1 postfix/postscreen[23626]: NOQUEUE: reject: RCPT from [159.183.156.68]:36108: 450 4.3.2 Please retry immediately; from=<bounces+24042819-b16d-deb=example....@em4258.hersheypa.com>, to=<d...@example.com>, proto=ESMTP, helo=<o1.ptr6670.hersheypa.com> SendGrid silently deleted them. We want your mail; please stop using SendGrid. Thanks for listening. _______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
