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

Reply via email to