I can't go into the specifics in great detail, but I want to make it clear that these are rare edge cases. We aren't out there retrying 5xx every chance we get because we don't care about being a good citizen. These are small scale, often short-lived exceptions where retrying a very specific 5xx results in immediate and reliable delivery.
One example: when a dozen customers complain about us permanently failing responses like *554 Temporarily Deferred, try again in 5 minutes *(Yeah, that's an actual response seen in the wild), and we flip it to a retry and watch the mail deliver consistently on the second or third attempt, we are inclined to leave it as a retry. It seems like getting more mail delivered to our customers' end recipients is a small price to pay for violating the spirit of an RFC in a few small, and well vetted edge cases. With that said, given the responses in this thread, we will be taking a close look at the few rules we have in place where we retry 5xx and see if A.) the rules are still being hit at all, and B.) are these retries still resulting in reliable and consistent delivery after a small number of attempts. Luke On Mon, Feb 27, 2023 at 2:01 PM Michael Orlitzky via mailop < mailop@mailop.org> wrote: > On Mon, 2023-02-27 at 04:55 +0000, Denny Watson via mailop wrote: > > > > All I have said (which you had conveniently redacted) is that RFC5321 > > leaves the door open to process bounces differently should the > > sending MTA be able to determine the reason for non-delivery.[1] > > > > ... > > > > [1] See my original email on this subject about section 4.5.4.1 of > > RFC5321 and why rejected mail can have a different queuing strategy > > based on the sender's interpretation of the 4xx response the it had > > received. > > I didn't redact it to make my argument seem stronger, I redacted it > because it's irrelevant. That's not what SendGrid is doing. And you > quoted the RFC out of context anyway. Here's the full text of the first > two paragraphs of that section for anyone too lazy to look it up: > > 4.5.4.1. Sending Strategy > > The general model for an SMTP client is one or more processes that > periodically attempt to transmit outgoing mail. In a typical > system, the program that composes a message has some method for > requesting immediate attention for a new piece of outgoing mail, > while mail that cannot be transmitted immediately MUST be queued and > periodically retried by the sender. A mail queue entry will include > not only the message itself but also the envelope information. > > The sender MUST delay retrying a particular destination after one > attempt has failed. In general, the retry interval SHOULD be at > least 30 minutes; however, more sophisticated and variable strategies > will be beneficial when the SMTP client can determine the reason for > non-delivery. > > It clearly states that messages must be retried. The "variable > strategies" you latched onto is in the context of how often the sender > should retry. > > I don't care if SendGrid takes your money and pipes your mail to > /dev/null but we can stop pretending that they're playing 4d chess with > RFC5321 now. > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://list.mailop.org/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
