MimePart: fixed not escaped header before encoded into utf-8 - #102
Conversation
0f3a919 to
4b6f672
Compare
af1d65e to
93bc1c9
Compare
5aeaf1e to
82f31ef
Compare
e5578f0 to
e220d35
Compare
d266800 to
189277a
Compare
d356e6e to
211bd8c
Compare
…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.
|
@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 #107 keeps your protection but limits it to characters that could restructure the address list for a receiver that re-parses the decoded phrase: Two things you're better placed to judge than I am:
Thanks |
…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.
…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.
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.