SMTPUTF8 problem & forwarding Problem


one problem with my new mailinabox system:
If i send a email from user to user.
For example send a email to with a “Ä,Ü or Ö” in the topic the user get back the following error message:
X-Postfix; SMTPUTF8 is required, but was not offered by host[]

What can i do ?


new situation.
I create a own Email Account with the address and make a filter to forward the emails.
Now it works… but new problem :slight_smile:
The forwarding works from 1 to 4 forwarding adresses.
If i add a fifth, the forwarding dont works. (it forwards no emails, no one becomes the email from 1 to 5)

Someone know this bug ?


Question … are the addresses all served by this MiaB or are they external to the server?


thanks for the quick answer.

Yes, all of the adresses are on my own MIB Server.
I´d like to use this function only for a distributor address.

For example: forwards to:
this config works…

if i add a additional email adress the forwarding dont works…

config via Roundcube…

So you are doing the ‘forwarding’ via a filter in RC? If that is the case, I shall propose an alternative (and better method, IMHO). Please confirm.

yes i do everything via RC

Go into the MiaB admin pages.

Under Mail>> Aliases create an alias:

Have the alias point to: … etc.

That should work. You just need to create alternate identities to respond as any of the other aliases when using the RC account.

Just curious … is this something that worked before, or is this the first time you have attempted in with 5 users? I am going to suggest that it is a Roundcube bug as you are using the filters in RC to do the forwarding. Once you set up and test my method, it will become clear that this is a RC issue assuming all works ok then.

first time i installed MIB i do the forwarding in the admin page.
Just as you described in your posting.

But in this way i have a problem with forwarding emails that contains “ÄÜÖ” in the topic or attachment.
Thats a problem from the german “ÄÖÜ” :slight_smile:

Then i switched to the roundcube filter variant.
This way have no problems with “ÄÖÜ” but:

Now i have the max 4 forwarding email problem :slight_smile:

Thank you

May I suggest that you open two threads in the issues area on the MiaB Github?

1 for the RC forwarding issue


1 for the character issue … for after all there may quite well be an easy fix for the latter.

Actually, thinking it through the RC issue is not something that we have any control over so scratch that, but I’d still think that the issue with using accents/umlauts/etc. is one that MiaB developers MAY be able to have some control over …

ok, before i do that.

I try to reproduce that problem with “ÄÖÜ”

The problem with the bigger than 4 forwards is definitely.
I write to MIAB Github.

Tomorrow i test a workaround: forward to:

and now: forwardto:

Just to clarify … you are running MiaB v0.41 (the most current release) correct? I assumed that from your initial comment, but there was an issue in v0.40 concerning this, so I want to absolutely confirm that you ARE using the most recent version.

MIB Admin Status:

Mail-in-a-Box is up to date. You are running version v0.41.

1 Like

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 ESMTP Hi, I'm a Mail-in-a-Box (Ubuntu/Postfix; see
ehlo desktop
250-SIZE 134217728

The line


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 ESMTP server ready
ehlo desktop hello [], pleased to meet you
250-SIZE 30000000
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.

  1. Turn off SMTPUTF8 on your server
  2. 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 at your service, []
250-SIZE 157286400

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.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.