Split encoded-words not recognised

Issues
1

Issue Description

Multiple encoded-words inside a quoted filename= / name= parameter are decoded one at a time and the whitespace between them is kept. Gmail and Outlook send long non-ASCII filenames this way, even though RFC 2047 section 5 doesn’t allow encoded-words in quoted strings. A correctly split name gets an extra space. A name split mid-character gets U+FFFD.

The charset labels cp949, x-windows-949 and UHC are not recognised. The text is then decoded with the wrong charset and comes out entirely garbled. ks_c_5601-1987, windows-949 and euc-kr work, including CP949-only characters such as 똠, so the decoder exists and only these names are missing.

Expected Behavior

  1. filename=“=?UTF-8?B?7KCV6riw7KCQ6rKA?= =?UTF-8?B?7JWI64K0LnBkZg==?=” gives 정기점검안내.pdf. The rule used for unstructured text should apply here too: whitespace between adjacent encoded-words is ignored (RFC 2047 section 6.2), and adjacent words in the same charset are joined before decoding.

  2. cp949, x-windows-949 and UHC are treated as aliases of windows-949, as Python (cp949, uhc) and Java (x-windows-949) already do.

Actual Behavior

  1. attachments.name is “정기점검 안내.pdf” (extra space). If the sender splits a character across two words, the name is “정기� ��검� �내.pd f”.

  2. Subject: =?cp949?B?waSx4sGhsMsgvsizuyCMYw==?= gives a garbled subject (“����ý��� …”) instead of “정기점검 안내 똠”. A body with Content-Type: text/plain; charset=cp949 is garbled the same way.

Reproduction Steps

  1. Import this message with Email/import, or deliver it over SMTP:

From: [email protected]
To: [email protected]
Subject: =?cp949?B?waSx4sGhsMsgvsizuyCMYw==?=
Date: Thu, 1 Oct 2026 10:00:00 +0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=“b”

–b
Content-Type: text/plain; charset=utf-8

hi
–b
Content-Type: application/pdf
Content-Disposition: attachment; filename=“=?UTF-8?B?7KCV6riw7KCQ6rKA?= =?UTF-8?B?7JWI64K0LnBkZg==?=”
Content-Transfer-Encoding: base64

JVBERi0xLjQK
–b–

  1. Run Email/get with properties [“subject”, “attachments”].
  2. subject is garbled and attachments[0].name is “정기점검 안내.pdf”.

Stalwart Version

v0.16.x

Installation Method

Built from source

Database Backend

RocksDB

Blob Storage

RocksDB

Search Engine

Internal

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

This looks like a genuine parsing issue rather than a documentation question, so I’ll flag it for human triage rather than guess at a fix.

Both behaviors you describe (not joining adjacent same-charset encoded-words across whitespace in quoted parameters, and missing cp949/x-windows-949/UHC as windows-949 aliases) live in the MIME header/charset decoding logic that Stalwart’s parser uses internally, not in anything exposed or documented at the configuration level. I was not able to find documentation or exposed configuration that would let this be worked around (there’s no charset-alias or encoded-word setting), which matches your finding that this is a decoder bug rather than a config gap.

A human maintainer will need to confirm and address this in the underlying parsing code, since it’s not something I can verify or fix by searching documentation.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

The first issue is because, as you suspected, the header violates RFC 2047, twice actually:

“An ‘encoded-word’ MUST NOT appear within a ‘quoted-string’.”
“An ‘encoded-word’ MUST NOT be used in parameter of a MIME Content-Type or Content-Disposition field, or in any structured field body except within a ‘comment’ or ‘phrase’.”

The second issue was due to a missing charset mapping in mail-parser which has been added just now.