I think you do need to understand exactly what’s happening here.
The original SMTP specification originally called for email to only use ASCII characters 0-127 or as it puts it 7 bit values right justified so the leading bit is always zero.
Later on a specification for passing UTF-8 characters over SMTP was included, HOWEVER the two parties MUST negotiate it’s use.
When a client greets a server it can use one of two commands.
HELO - which is meant to indicate it uses the original subset of SMTP codes.
EHLO - which indicates to the server that the client is able to use Enhanced SMTP abilities.
The server in reply sends back a list of capabilities
220 box.timothydutton.co.uk ESMTP Hi, I'm a Mail-in-a-Box (Ubuntu/Postfix; see https://mailinabox.email/)
ehlo desktop
250-box.timothydutton.co.uk
250-PIPELINING
250-SIZE 134217728
250-VRFY
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-DSN
250 SMTPUTF8
The line
250 SMTPUTF8
Indicates that the server will allow UTF-8 characters to be sent. However the sending party does also have to issue an SMTPUTF8 command first.
However this means the email that is sent now has 8 bit values instead of 7 bit values.
So what happens if it wants to forward on that mail.
Before I continue it’s important to note that the SMTP standard states that a mail cannot be altered by an SMTP server - apart from adding trace headers to the start of the mail.
This means that once the server has accepted a mail with UTF-8 Characters, it can only send it on to another server that accepts UTF8 characters.
Lets look at a real world mail exchanger this one belongs to Virgin Media
220 mx6.tb.ukmail.iss.as9143.net mx6.tb.ukmail.iss.as9143.net ESMTP server ready
ehlo desktop
250-mx4.tb.ukmail.iss.as9143.net hello [77.68.89.100], pleased to meet you
250-HELP
250-SIZE 30000000
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 OK
We see here that there is no line indicating the server supports UTF-8 chracters.
So our server now has a mail it wants to forward but can’t as the receiving party won’t accept it. Hence the error.
There are two solutions to this problem.
- Turn off SMTPUTF8 on your server
- The recipient turns on SMTPUTF8 on their server.
The first will stop you receiving mails you can’t forward on, BUT maintains the status quo.
The second will mean that eventually every email provider may support SMTPUTF8, but is a long slog in the meantime.
Edit - For Comparison here’s a list of Google’s ablilities as advertised by it’s Mail Exchanger
ehlo desktop
250-mx.google.com at your service, [77.68.89.100]
250-SIZE 157286400
250-8BITMIME
250-ENHANCEDSTATUSCODES
250-PIPELINING
250-CHUNKING
250 SMTPUTF8
So we can see that if the OP was forwarding the mail to an address supported by Google - Gmail or GSuite managed email, the forward would work.