Default behavior is always to retry 4xx if there isn't a rule in place that overrides it. In this case, it was, and still is (i'm working on it) hitting another rule that was put in place to *not* retry a very specific 4xx that would never result in a successful delivery.
The full response in question is this: 450 4.3.2 Please retry immediately. If your message was rejected by a blacklist, see http://michael.orlitzky.com/articles/so_youre_blacklisted.xhtml for more information. The bit of text in the string causing the trouble is the word blacklist. Unfortunately, we see a number of 4xx responses that contain the word blacklist and retries never succeed. For example, "450 4.3.2 your message was rejected because you're on a blacklist" is *not *retried because it's useless and *not* retrying is the appropriate thing to do for our customers. The response we are talking about here matches the response code, enhanced code, and contains the word blacklist. It's a rule collision that we can and will solve for. What really confuses me about this discussion is the almost religious fervor around the idea that under no circumstances should a 4xx not be retried and under no circumstances should a 5xx ever be retried. Anyone who has spent more than an hour reviewing SMTP responses for a large-scale mail system knows this is not true. But here we are. Smart, well intended people saying what is known to be false. It's Pravda-esque. It's the Emperor's New Clothes. I'm happy to be the one to say the emperor is naked and take my licks here. On Fri, Jun 23, 2023 at 12:15 PM Andy Smith via mailop <mailop@mailop.org> wrote: > Hi, > > On Fri, Jun 23, 2023 at 08:03:40PM +0200, Carsten Schiefner via mailop > wrote: > > how about elaborating a bit further on the whats and whys of your setup? > > Maybe some of us could learn something from that, or maybe SendGrid > would consider that to be giving an advantage to competitors. Really > what I am interested in is the justification for not even retrying > once when receiving the "450 4.3.2 Please retry immediately" > response described by the OP. > > If I understand correctly, the OP had experienced missing mail from > SendGrid previously, had asked why there had not been retries on > a 4xx, and was told that SendGrid uses a complex rule set to decide > whether to actually retry for any given 4xx or 5xx. The OP then > tested that by coming up with "450 4.3.2 Please retry immediately", > which also did not receive any retries at all. > > So this implies that if SendGrid sees a "450 4.3.2" response that it > does not otherwise have a special rule for (or is it any 4xx that > there is no rule for?) then discarding the mail without any retries > at all is what happens by default. > > The idea of not retrying at all on certain specific 4xx responses > doesn't sit that well with me, but I can kinda sorta see why a large > sender might want to do that if they were really sure. But here > seems to be the implication that it's actually quite easy to trigger > that behaviour, unless by some stroke of bad luck "450 4.3.2 Please > retry immediately" happened to match an existing rule. > > It would be useful to know if it is the case that if one uses a 4xx > response that SendGrid hasn't seen before, it's going to result in > no actual retries. > > Thanks, > Andy > > -- > https://bitfolk.com/ -- No-nonsense VPS hosting > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
