[Bug]: S/MIME: non-ASCII recipient display names cause RFC/header rejection by IONOS

[JuergenTenckhoff]

Description

When sending an S/MIME-signed message with the Bulwark S/MIME plugin, delivery to IONOS / 1&1 fails if the recipient has a non-ASCII character in the display name.

The same S/MIME-signed message is accepted by the same IONOS recipient when only the bare email address is used.

This appears to be related to the way the S/MIME MIME builder serializes address display names.

Steps to Reproduce

1. Configure S/MIME in Bulwark and import a valid signing certificate.

2. Create a new message to an IONOS / 1&1 recipient.

3. Use only the bare recipient address, for example:

   recipient@example.de

4. Sign the message with S/MIME and send it.

   Result: the message is accepted by IONOS.

5. Create another new message to the same recipient.

6. This time select a contact whose display name contains a non-ASCII character, for example:

   "Test Müller" <recipient@example.de>

7. Sign the message with S/MIME and send it.

   Result: IONOS rejects the message after SMTP DATA.

No reply headers (In-Reply-To or References) are involved in this reproduction.

Expected Behavior

S/MIME-signed messages should be delivered successfully when recipient display names contain non-ASCII characters such as ü, ö, ä, ß, or other accented/international characters.

The generated address header should be encoded in an RFC-compliant way, or the message should otherwise be handled correctly as SMTPUTF8 throughout the delivery path.

Actual Behavior

The S/MIME-signed message is accepted when the recipient header contains only the bare address:

To: recipient@example.de

The same message is rejected by IONOS when the recipient contains a non-ASCII display name:

To: "Test Müller" <recipient@example.de>

IONOS rejects the message after DATA with:

554 Transaction failed
Reject due to policy restrictions
case: r0735

S/MIME-signed messages to another mail provider are accepted and the signatures verify correctly.

Bulwark Version

1.8.1

Stalwart Mail Server Version

0.16.17

Browser

No response

Operating System

None

Screenshots / Screen Recording

No response

Relevant Logs or Error Output

`IONOS / 1&1 SMTP response:

554 Transaction failed
Reject due to policy restrictions
case: r0735

Accepted S/MIME recipient header:

To: recipient@example.de

Rejected S/MIME recipient header:

To: "Test Müller" recipient@example.de

### Additional Context

Environment:

- S/MIME plugin: 1.0.2
- Mail server: Stalwart
- Recipient MX: IONOS / 1&1
- S/MIME type: `application/pkcs7-mime; smime-type=signed-data`

Control tests:

- S/MIME-signed mail to another mail provider is accepted.
- The S/MIME signature is valid and can be verified by other receiving systems.
- S/MIME-signed mail to the same IONOS recipient is accepted when only the bare email address is used.
- The rejection can therefore be reproduced specifically by adding a non-ASCII display name.

Possible cause:

In `smime/src/mime-builder.js`, `formatAddress()` appears to serialize display names directly:

    function formatAddress(addr) {
      if (addr.name) {
        const escaped = addr.name
          .replace(/\\/g, '\\\\')
          .replace(/"/g, '\\"');
        return `"${escaped}" <${addr.email}>`;
      }
      return addr.email;
    }

This can produce a raw UTF-8 address header such as:

    To: "Test Müller" <recipient@example.de>

The normal non-S/MIME message path does not show this interoperability problem.

Workaround:

Using only the bare recipient address works:

    To: recipient@example.de

[JuergenTenckhoff]

Additional control test:

I sent another S/MIME-signed message to the same IONOS recipient, with:

• S/MIME signing enabled

• no read-receipt / MDN request

• no CC recipient

• same recipient email address

• recipient display name changed from:

  "Tanja Bürgelin-Arslan"

  to:

  "Tanja Buergelin-Arslan"

The message was accepted by IONOS and no 554 / r0735 rejection occurred.

So changing only the non-ASCII character in the recipient display name appears to remove the IONOS rejection.

This strongly supports the original suspicion that the problem is related to the serialization/encoding of non-ASCII recipient display names in the S/MIME MIME builder, rather than to S/MIME itself, CC handling, or MDN/read-receipt headers.

[JuergenTenckhoff]

Additional reproduction on the current setup:

The issue is still reproducible with Bulwark 1.9.2 and Stalwart 0.16.20.

Test case:

• S/MIME signing enabled
• recipient: "Test Müller" <recipient@example.de>
• Subject: Test
• no long/non-ASCII Subject involved

IONOS again rejected the message after DATA with:

554 Transaction failed
Reject due to policy restrictions
case: r0735

The DSN returned by Stalwart contained the original rejected message as a message/rfc822 attachment.

Inspecting that original message confirms that the recipient display name is serialized as raw UTF-8 in the To: header:

From: sender@example.org
To: "Test Müller" <recipient@example.de>
Subject: Test
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"

So this reproduces the original finding on Bulwark 1.9.2 and provides direct evidence from the actual rejected RFC 822 message: the non-ASCII recipient display name is still emitted unencoded in the S/MIME message header.

This test is also independent of issue #7 (long non-ASCII Subject folding), since the Subject here was simply Test.