Bug: S/MIME: long non-ASCII Subject headers are folded inside RFC 2047 encoded-words

[JuergenTenckhoff]

Description

When sending an S/MIME-signed message with a longer Subject containing non-ASCII characters, the Bulwark S/MIME MIME builder can fold the Subject header inside an RFC 2047 encoded-word.

In the observed case, the line break occurred even in the middle of the UTF-8 encoding of the character ö.

This results in a malformed RFC 2047 Subject header.

Steps to Reproduce

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

2. Create a new S/MIME-signed message.

3. Use a sufficiently long Subject containing a non-ASCII character, for example:

   AW: Dein Wikipedia-Artikel ist jetzt veröffentlicht

4. Send the message.

5. Inspect the raw message headers.

Observed Subject header:

Subject: =?UTF-8?Q?AW=3A=20Dein=20Wikipedia=2DArtikel=20ist=20jetzt=20ver=C3
 =B6ffentlicht?=

The encoded-word is folded before it has been completed.

Expected Behavior

RFC 2047 encoded-words should not be split by ordinary header folding.

If the encoded Subject is too long, Bulwark should generate multiple complete RFC 2047 encoded-words and fold only between them.

For example, a long Unicode Subject should be encoded as several valid encoded-words rather than inserting a line break inside one encoded-word.

Actual Behavior

Bulwark generates one RFC 2047 encoded-word for the non-ASCII Subject and then applies generic header folding to the completed header.

This can result in a header such as:

Subject: =?UTF-8?Q?AW=3A=20Dein=20Wikipedia=2DArtikel=20ist=20jetzt=20ver=C3
 =B6ffentlicht?=

In this example, the UTF-8 representation of ö (C3 B6) is effectively split across the folded header:

=C3
 =B6

The resulting Subject header is not valid RFC 2047 encoding.

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

Observed raw Subject header:

Subject: =?UTF-8?Q?AW=3A=20Dein=20Wikipedia=2DArtikel=20ist=20jetzt=20ver=C3
 =B6ffentlicht?=

The line break occurs inside a single RFC 2047 encoded-word and also splits the encoded UTF-8 character `ö` (`=C3=B6`).

Additional Context

Environment:

• S/MIME plugin: 1.0.2
• Mail server: Stalwart
• S/MIME type: application/pkcs7-mime; smime-type=signed-data

The issue appears to be in smime/src/mime-builder.js.

encodeHeaderValue() first creates a single RFC 2047 encoded-word for a non-ASCII Subject.

The resulting value is then passed through the generic formatHeader() folding logic, which folds long headers without being aware of RFC 2047 encoded-word boundaries.

Conceptually, the current flow is:

encodeHeaderValue(subject)
    -> one long =?UTF-8?Q?...?= encoded-word

formatHeader("Subject", encodedValue)
    -> generic folding at approximately 76 characters

This can insert a CRLF inside the encoded-word.

A possible fix would be to split long encoded Subjects into multiple complete RFC 2047 encoded-words before header folding, ensuring that each encoded-word remains within the RFC 2047 length limit and that folding occurs only between encoded-words.

This issue is separate from the previously reported IONOS/non-ASCII recipient display-name problem.