On 2/26/2023, Michael Orlitzky via mailop wrote:
On Sun, 2023-02-26 at 19:43 +0000, Denny Watson via mailop wrote:
This appears to be a specially built MTA, and with the (probable)
consent of its users, has policy in place to not resend after 4xx under
specific conditions. I.e. the sending MTA is interpreting specific 4xx
responses (and more likely the text) to mean a permanent failure.
I do not see a problem with elevating a 4xx to mean 5xx where the users
of the system understand the policy as it does not appear to impact the
receiving system.
This is not whatever subtle and nuanced situation you are imagining
though. The users don't know, and the response code/text makes no
difference.
I'm going to have to take your word for it as;
* I have never read Sendgrid's contracts, nor their user documentation.
* I do not know if this is what Sendgrid is actually doing, and if they
are, that they are not also attempting to send at least one more time.
* I do not know if this is a user configurable setting.
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] I'll add also
that RFC5321 specifically says under section 4.2.1;
4yz Transient Negative Completion reply
The command was not accepted, and the requested action did not occur.
However, the error condition is temporary, and the action may be
requested again. The sender should return to the beginning of the
command sequence (if any). It is difficult to assign a meaning to
"transient" when two different sites (receiver- and sender-SMTP agents)
must agree on the interpretation. Each reply in this category might
have a different time value, but the SMTP client SHOULD try again. A
rule of thumb to determine whether a reply fits into the 4yz or the 5yz
category (see below) is that replies are 4yz if they can be successful
if repeated without any change in command form or in properties of the
sender or receiver (that is, the command is repeated identically and the
receiver does not put up a new implementation).
Please note "However, the error condition is temporary, and the action
_MAY_ be requested again" (emphases added) and "[...] but the SMTP
client SHOULD try again." Note the use of SHOULD and not MUST.
Again, without further detail on actual operation and/or an
understanding of what the users of the system have been told, I can not
comment specifically about Sendgrid's MTAs today.[2]
[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.
[2] I have twice pulled one of their folks aside to inform them that
their MTAs were not fully compliant with the RFCs, and they corrected
the problems swiftly. But because I do not have evidence here, I can
not specifically state that this is or is not the case.
--
Denny Watson
Lead Investigator
The Spamhaus Project
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
