That would be something you would need to take up with the original sender’s provider, as it is their mail server (and/or system) being broken.
Or, if there are other intermediates in the line between them and before Cloudflare, it would be the latest one of them, which actually “accepted” the message.
Here’s another one:
I assume that is the kind of bounce you refer to?
If the original sender didn’t get a such kind of Non Delivery Report (NDR) from their (provider’s) mail server, the problem is on their( provider’s) end.
Cloudflare never accepted the message, as such, Cloudflare is not responsible for generating the Non Delivery Report (NDR), that would be on sender’s mail server’s responsibility, until Cloudflare had accepted the message.
Cloudflare is literally, as a SMTP proxy, saying “Hang on, I’ll ask the upstream (final destination) what they want to do with this message, and let you know” while the transmission is still open, which means if the upstream (final destination) rejects it, Cloudflare will reject the transmission from the original sender too.
If Cloudflare had done the store-and-forward approach, and said “OK, I accept the message, and deal with it later”, then your statement would be correct, and the generation of the Non Delivery Report (NDR) would be on Cloudflare’s responsibility.
Accepting the message and dealing with it later most often open up your MTA to become a potential Gatling gun for useless noise (also known as “backscatter”).
The responsibility for generating the Non Delivery Report (NDR) reside with the latest server “accepting” the message.
$ telnet amir.mx.cloudflare.net 25
Trying 162.159.205.11...
Connected to amir.mx.cloudflare.net.
Escape character is '^]'.
220 mx.cloudflare.net Cloudflare Email ESMTP Service ready
EHLO mail.example.invalid
250-mx.cloudflare.net greets mail.example.invalid
250-STARTTLS
250-8BITMIME
250 ENHANCEDSTATUSCODES
MAIL FROM: <[email protected]>
250 2.1.0 Ok
RCPT TO: <[email protected]>
250 2.1.0 Ok
DATA
354 Start mail input; end with <CR><LF>.<CR><LF>
From: <[email protected]>
To: <[email protected]>
Subject: hi there
Date: Thu, 13 Apr 2023 16:01:23 +0200 (CEST)
Message-ID: <something.random@getting-rejected-by-final-destination.example.net>
hello
.
521 5.3.0 Upstream error, please check https://developers.cloudflare.com/email-routing/postmaster for possible reasons why. {queue-id}
Connection closed by foreign host.
Above transcript where Cloudflare in the end responds “521 5.3.0”, doesn’t equal “accepting the message”.
For the screenshots above:
- Me ↔
smtp.gmail.com (Google)
- Google ↔ Cloudflare
- Cloudflare ↔ My mail server
Since Cloudflare returned 521 5.3.0 to Google, because I returned 550 5.7.1 to Cloudflare, the latest server accepting the responsibility for the message was actually smtp.gmail.com (Google).
As per the second screenshot, Google fulfilled that responsibility, and generated the Non Delivery Report (NDR) as they were supposed to.
→ Backscatter (email) - Wikipedia
Mail transfer agents (MTAs) which forward mail can avoid generating backscatter by using a transparent SMTP proxy.
→ SMTP proxy - Wikipedia
SMTP proxies are specialized mail transfer agents (MTAs) that, similar to other types of proxy servers, pass SMTP sessions through to other MTAs without using the store-and-forward approach of a typical MTA. When an SMTP proxy receives a connection, it initiates another SMTP session to a destination MTA. Any errors or status information from the destination MTA will be passed back to the sending MTA through the proxy.[1]
… which is how Cloudflare does the forward, and why they are not responsible for generating the Non Delivery Report (NDR).
Sounds indeed like there are no way out other than that.
That said, I wish you good luck with your email forwarding./ routing!
