Skip to content

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

Description

@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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions