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
