Skip to content

MimePart: fixed not escaped header before encoded into utf-8 - #102

Merged
dg merged 1 commit into
nette:masterfrom
Daaarkling:fix-escaping
Apr 23, 2026
Merged

MimePart: fixed not escaped header before encoded into utf-8#102
dg merged 1 commit into
nette:masterfrom
Daaarkling:fix-escaping

Conversation

@Daaarkling

@Daaarkling Daaarkling commented Oct 10, 2024

Copy link
Copy Markdown
Contributor
  • bug fix
  • BC break? no

Headers containing special characters such as Czech characters also need to be escaped before converting to utf-8.

Example header From: Kdo uteče, obědvá <doe@example.com>

When google processes the email, it misparses the comma and because of that the DKIM signature verification fails and the email is rejected.

@dg
dg force-pushed the master branch 4 times, most recently from af1d65e to 93bc1c9 Compare December 30, 2025 00:48
@dg
dg force-pushed the master branch 2 times, most recently from 5aeaf1e to 82f31ef Compare February 10, 2026 02:48
@dg
dg force-pushed the master branch 5 times, most recently from e5578f0 to e220d35 Compare February 24, 2026 16:12
@dg
dg force-pushed the master branch 10 times, most recently from d266800 to 189277a Compare March 31, 2026 17:42
@dg
dg force-pushed the master branch 2 times, most recently from d356e6e to 211bd8c Compare April 23, 2026 21:06
@dg
dg merged commit af13a00 into nette:master Apr 23, 2026
dg pushed a commit that referenced this pull request Apr 23, 2026
…ncoding (#102)

When a name in From/To/Cc contained characters outside RFC 2822 atext
(e.g. comma or quote in a UTF-8 name), it was base64-encoded as-is. After
the recipient decoded it, the raw special chars reappeared in the phrase
and could be misparsed (a comma would split one address into two).

Wrap such phrases in quoted-string before encoding, so the decoded form
is a valid quoted phrase. Applies only to the phrase part of address
headers, not to Content-Disposition filename values.
@hubipe

hubipe commented Aug 18, 2026

Copy link
Copy Markdown
Contributor

@Daaarkling I'd welcome your eyes on #107, which narrows the predicate this PR added.

The escape introduced here fires on any character outside RFC 2822 atext, and that includes every accented letter. Because the quoting happens before iconv_mime_encode(), the quotes end up inside the base64 payload, and clients display them as part of the name – every sender or recipient with diacritics in the name now renders as "Objednávky domena.cz" instead of Objednávky domena.cz.

#107 keeps your protection but limits it to characters that could restructure the address list for a receiver that re-parses the decoded phrase: , ; : < > @ " \. Your motivating case is unchanged – Kdo uteče, obědvá still encodes as a quoted-string, and Mail.headers.002.phpt now asserts that explicitly.

Two things you're better placed to judge than I am:

  1. Is that character set sufficient, or did the Gmail failure you saw involve any character outside it?
  2. If you still have access to the original setup, does DKIM verification at Gmail still pass with the narrowed rule?

Thanks

dg pushed a commit that referenced this pull request Aug 18, 2026
…ed (#107)

whenever it contained anything outside RFC 2822 atext. Every accented letter
is outside atext, so every non-ASCII name was quoted, and because the quotes
land inside the base64 payload, clients showed them as part of the name:
"Objednávky domena.cz" instead of Objednávky domena.cz.

Per RFC 2047 §6.2 an encoded-word is decoded only after the field is parsed,
so quotes there are not syntax; they only guard against a receiver that
decodes first and re-parses the result (the Gmail failure behind #102).
The encoded path therefore quotes only names holding a character such a
receiver could turn into another address (,;:<>@"\); diacritics and dots
are encoded bare. The literal path keeps the atext test, where the quotes
are real RFC 5322 delimiters.
dg pushed a commit that referenced this pull request Aug 18, 2026
…ed (#107)

whenever it contained anything outside RFC 2822 atext. Every accented letter
is outside atext, so every non-ASCII name was quoted, and because the quotes
land inside the base64 payload, clients showed them as part of the name:
"Objednávky domena.cz" instead of Objednávky domena.cz.

Per RFC 2047 §6.2 an encoded-word is decoded only after the field is parsed,
so quotes there are not syntax; they only guard against a receiver that
decodes first and re-parses the result (the Gmail failure behind #102).
The encoded path therefore quotes only names holding a character such a
receiver could turn into another address (,;:<>@"\); diacritics and dots
are encoded bare. The literal path keeps the atext test, where the quotes
are real RFC 5322 delimiters.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants