Repository navigation
fix: join adjacent MIME encoded words before decoding multibyte text - #182
charan-rathore wants to merge 1 commit into
Conversation
Signed-off-by: Charan Rathore <180254320+charan-rathore@users.noreply.github.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8b24bc9b75
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "latin1", | ||
| ); | ||
| if (pending !== null && normalized === pendingCharset) { | ||
| pending = Buffer.concat([pending, bytes]); |
There was a problem hiding this comment.
When an incoming Gmail Subject or From contains thousands of adjacent same-charset encoded words, this loop copies the entire accumulated prefix for every word, making decodeHeader quadratic in header size. The mapMessage path accepts unrestricted header strings up to the whole-response limit, so a sufficiently large folded header can cause seconds of CPU time and heavy allocation churn whenever the message is listed or opened; collect the byte chunks and call Buffer.concat once in flush() instead.
Useful? React with 👍 / 👎.
This branch has not been deployed
1 participant
Summary
A sender that wraps a long header at the RFC 2047 encoded-word length limit can break a multibyte character across two adjacent encoded words.
decodeHeaderglued the words' whitespace together (#130) but still decoded each word on its own, so the split bytes each became U+FFFD:=?UTF-8?B?...w6?==?UTF-8?B?qQ==?=rendered ascaf��instead ofcafé.Fix
Per RFC 2047 §6.2, adjacent encoded words are concatenated before decoding. The decoder now matches a run of adjacent words, joins the raw bytes of consecutive same-charset words, and decodes each joined group once. Unknown charsets keep the existing fallback of printing the original words verbatim, and words separated by plain text still decode independently.
Test
mail joins adjacent encoded words that split a multibyte charactercovers base64 and quoted-printable splits, including a fold-separated pair; it fails on main with replacement characters and passes with the join. The fulltests/google.test.tssuite passes (37/37), andtsc --noEmitandbiome checkare clean.