fix: quote display names with RFC 2822 special characters in +reply by richandersonio · Pull Request #513 · googleworkspace/cli

richandersonio · 2026-03-16T08:02:55Z

Summary

Re-quote ASCII display names in encode_address_header() when they contain RFC 2822 special characters (,;()<>@\".[])
Adds two test cases for display names with commas and parentheses

Problem

gws gmail +reply fails with Invalid To header (HTTP 400) when replying to emails where the sender's display name contains commas or parentheses — common with corporate email (Outlook/Exchange) which uses formats like "Anderson, Rich (CORP)" <email@adp.com>.

The root cause: encode_address_header() strips quotes from the display name via extract_display_name(), then reconstructs the address without re-quoting. The unquoted comma makes it look like two malformed mailboxes, and unquoted parentheses are interpreted as RFC 2822 comments.

Fix

One-line change in encode_address_header(): check if the display name contains special characters and wrap in quotes if so.

Test plan

cargo test -- test_encode_address_header — all 14 tests pass (12 existing + 2 new)
New test: test_encode_address_header_display_name_with_comma — verifies "Anderson, Rich (CORP)" stays quoted
New test: test_encode_address_header_display_name_with_parens — verifies Rich (CORP) gets quoted

Fixes #512

changeset-bot · 2026-03-16T08:02:59Z

🦋 Changeset detected

Latest commit: df6a097

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@googleworkspace/cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

google-cla · 2026-03-16T08:02:59Z

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

gemini-code-assist · 2026-03-16T08:03:08Z

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical issue where the gws gmail +reply functionality failed when replying to emails with sender display names containing RFC 2822 special characters like commas or parentheses. The change ensures that such display names are properly quoted in the email header, resolving the Invalid To header error and improving compatibility with various email formats, particularly those from corporate systems.

Highlights

RFC 2822 Quoting Fix: Implemented a fix in encode_address_header() to correctly re-quote ASCII display names that contain RFC 2822 special characters (e.g., commas, parentheses) to prevent header parsing issues.
New Test Cases: Added two new test cases (test_encode_address_header_display_name_with_comma and test_encode_address_header_display_name_with_parens) to validate the correct handling of display names with special characters.

Changelog

src/helpers/gmail/mod.rs
- Modified encode_address_header to conditionally re-quote display names if they contain RFC 2822 special characters, preventing malformed headers.
- Added two new unit tests to verify the correct quoting behavior for display names with commas and parentheses.

Activity

No human activity has occurred on this pull request yet.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Generative AI Prohibited Use Policy, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request correctly addresses an issue where display names with special characters were not being properly quoted, leading to email header parsing errors. The fix involves checking for RFC 2822 special characters and re-quoting the display name when necessary. The added test cases are good and cover the scenarios described. I've found one minor omission in the list of special characters that should be addressed, as detailed in the specific comment.

gemini-code-assist · 2026-03-16T08:07:14Z

src/helpers/gmail/mod.rs

-            format!("{} <{}>", display, email)
+            // Re-quote if the display name contains RFC 2822 special characters
+            // (commas, parens, etc.) to prevent header parsing issues.
+            if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {


The list of special characters to check for is missing the colon (:). According to RFC 5322, the colon is one of the specials that requires the display name to be quoted. Without this, a display name like Group: Work would not be quoted, potentially leading to it being misinterpreted as a group address syntax.

Suggested change

if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {

if display.contains(|c: char| ":,;()<>@\\\".[]".contains(c)) {

googleworkspace-bot · 2026-03-16T08:10:44Z

/gemini review

googleworkspace-bot · 2026-03-16T08:14:39Z

/gemini review

gemini-code-assist

Code Review

This pull request aims to fix an issue with unquoted special characters in email display names, which is a valid problem. The approach of re-quoting display names containing special characters is correct. However, the implementation for escaping quotes within the display name (display.replace('"', "\\\"")) introduces a critical regression. It will corrupt display names that already contain correctly escaped quotes, leading to malformed email headers. I've left a detailed comment on the specific line with an explanation of the issue. The new tests are a good addition but should be expanded to cover display names with quotes to catch this kind of regression.

gemini-code-assist · 2026-03-16T08:14:39Z

src/helpers/gmail/mod.rs

+            // Re-quote if the display name contains RFC 2822 special characters
+            // (commas, parens, etc.) to prevent header parsing issues.
+            if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {
+                format!("\"{}\" <{}>", display.replace('"', "\\\""), email)


The current implementation display.replace('"', "\\\"") introduces a critical regression. It incorrectly handles display names that already contain escaped quotes.

For example, if the original header has a display name like "Rich \"The Man\" Anderson", extract_display_name will return Rich \"The Man\" Anderson. Your new logic will then transform this into Rich \\\"The Man\\\" Anderson, resulting in a malformed header "Rich \\\"The Man\\\" Anderson" <email> when quoted.

This happens because .replace() acts on all " characters, without considering if they are already part of an escape sequence.

A correct implementation must handle escaping more carefully. Given that display may contain already-escaped characters, a simple string replacement is not sufficient. A more robust solution would be to iterate through the string to build a properly escaped version, or to first unescape the display string completely and then re-escape it for quoting.

I recommend rethinking this escaping logic to avoid this regression. You should also add a test case for a display name containing a quote to prevent this in the future.

gemini-code-assist

Code Review

The pull request effectively addresses the issue of +reply failing when display names contain RFC 2822 special characters by implementing logic to re-quote such display names. The addition of new test cases specifically validates these scenarios, improving the robustness of header encoding. However, the list of special characters checked for re-quoting is incomplete, potentially leading to malformed headers for display names containing colons or periods.

gemini-code-assist · 2026-03-16T08:16:34Z

src/helpers/gmail/mod.rs

-            format!("{} <{}>", display, email)
+            // Re-quote if the display name contains RFC 2822 special characters
+            // (commas, parens, etc.) to prevent header parsing issues.
+            if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {


The list of RFC 2822 special characters used to determine if a display name needs re-quoting is incomplete. According to RFC 5322 (section 3.2.3), the characters : (colon) and . (period) are also considered 'specials' and require the display name to be quoted if they appear outside of a quoted-string context. Since extract_display_name strips surrounding quotes, a display name like My:Name or First.Last would not be re-quoted by the current logic, leading to an invalid header.

This can result in malformed email headers and potential delivery issues or incorrect parsing by email clients.

Suggested change

if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {

if display.contains(|c: char| ",;()<>@\".[]:.".contains(c)) {

googleworkspace-bot · 2026-03-16T08:24:54Z

/gemini review

gemini-code-assist

Code Review

This pull request correctly addresses an issue where display names containing special characters were not being properly quoted, leading to header parsing errors. The implementation is robust in handling already-escaped characters within the display name. I've found one minor omission in the list of special characters that should be addressed to make the fix more complete.

gemini-code-assist · 2026-03-16T08:26:29Z

src/helpers/gmail/mod.rs

-            format!("{} <{}>", display, email)
+            // Re-quote if the display name contains RFC 2822 special characters
+            // (commas, parens, etc.) to prevent header parsing issues.
+            if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {


The list of special characters used to determine if a display name needs quoting appears to be missing the colon (:) character. According to RFC 2822 (section 3.2.1), the colon is considered a "special" character and should not appear in an unquoted atom. An unquoted display name containing a colon could lead to header parsing issues, similar to the ones this PR is fixing for commas and parentheses. It would be more robust to include it in the check.

Suggested change

if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {

if display.contains(|c: char| ",;()<>@\\\":.[]:".contains(c)) {

When replying to emails from corporate senders with display names like "Anderson, Rich (CORP)" <email@adp.com>, the +reply command fails with "Invalid To header" (400) from the Gmail API. The root cause: encode_address_header() strips quotes from the display name via extract_display_name(), then reconstructs the address without re-quoting. When the display name contains RFC 2822 special characters (commas, parentheses), the unquoted form is ambiguous — commas split it into multiple malformed mailboxes and parentheses are interpreted as RFC 2822 comments. Fix: re-quote the display name when it contains any RFC 2822 special characters, using a single-pass character iterator that preserves already-escaped sequences and escapes bare quotes/backslashes. Fixes googleworkspace#512

googleworkspace-bot · 2026-03-16T08:31:11Z

/gemini review

gemini-code-assist

Code Review

This pull request addresses an issue with incorrect quoting of email display names that contain special characters, which could lead to malformed headers. The proposed solution correctly identifies when a display name needs to be quoted and handles existing escaped characters. My review points out a minor omission in the list of special characters being checked, which could cause issues in other edge cases. The overall approach and the addition of new tests are well-executed.

gemini-code-assist · 2026-03-16T08:33:08Z

src/helpers/gmail/mod.rs

-            format!("{} <{}>", display, email)
+            // Re-quote if the display name contains RFC 2822 special characters
+            // (commas, parens, etc.) to prevent header parsing issues.
+            if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {


According to RFC 2822, the list of specials characters that require a display name to be quoted also includes the colon (:). This character is currently missing from your check.

While less common in display names than commas or parentheses, omitting it could lead to incorrectly formatted headers if a name like "Location: Main Office" <main@example.com> is processed.

Please add the colon to the list of special characters to ensure full compliance and prevent potential parsing issues.

Suggested change

if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {

if display.contains(|c: char| ",;()<>@:\\\"..[]".contains(c)) {

googleworkspace-bot · 2026-03-16T08:35:47Z

/gemini review

gemini-code-assist

Code Review

This pull request addresses an issue where email display names containing special characters were not being quoted correctly, leading to invalid headers. The fix introduces logic to detect RFC 2822 special characters and then properly quote and escape the display name, including a mechanism to avoid double-escaping already-escaped characters. The new unit tests effectively cover the main scenarios. I have one suggestion to make the fix more complete.

gemini-code-assist · 2026-03-16T08:42:42Z

src/helpers/gmail/mod.rs

-            format!("{} <{}>", display, email)
+            // Re-quote if the display name contains RFC 2822 special characters
+            // (commas, parens, etc.) to prevent header parsing issues.
+            if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {


The list of special characters used to determine if a display name needs quoting is missing the colon (:). According to RFC 2822 and RFC 5322, the colon is a special character that requires the display name to be quoted if present. Without this, a display name containing a colon could result in a malformed header.

Suggested change

if display.contains(|c: char| ",;()<>@\\\".[]".contains(c)) {

if display.contains(|c: char| ",;()<@:\\\".[]".contains(c)) {

googleworkspace-bot added the area: core Core CLI parsing, commands, error handling, utilities label Mar 16, 2026

gemini-code-assist bot reviewed Mar 16, 2026

View reviewed changes

richandersonio force-pushed the fix/reply-display-name-quoting branch from 462e59f to 2aa19b9 Compare March 16, 2026 08:30

gemini-code-assist bot reviewed Mar 16, 2026

View reviewed changes

retrigger CLA check

df6a097

gemini-code-assist bot reviewed Mar 16, 2026

View reviewed changes

	if display.contains(\|c: char\| ",;()<>@\\\".[]".contains(c)) {
	if display.contains(\|c: char\| ":,;()<>@\\\".[]".contains(c)) {

	if display.contains(\|c: char\| ",;()<>@\\\".[]".contains(c)) {
	if display.contains(\|c: char\| ",;()<>@\".[]:.".contains(c)) {

	if display.contains(\|c: char\| ",;()<>@\\\".[]".contains(c)) {
	if display.contains(\|c: char\| ",;()<>@:\\\"..[]".contains(c)) {

	if display.contains(\|c: char\| ",;()<>@\\\".[]".contains(c)) {
	if display.contains(\|c: char\| ",;()<@:\\\".[]".contains(c)) {

Conversation

richandersonio commented Mar 16, 2026

Summary

Problem

Fix

Test plan

Uh oh!

changeset-bot bot commented Mar 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

🦋 Changeset detected

Uh oh!

google-cla bot commented Mar 16, 2026

Uh oh!

gemini-code-assist bot commented Mar 16, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

googleworkspace-bot commented Mar 16, 2026

Uh oh!

googleworkspace-bot commented Mar 16, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

googleworkspace-bot commented Mar 16, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

googleworkspace-bot commented Mar 16, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

googleworkspace-bot commented Mar 16, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Mar 16, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

changeset-bot bot commented Mar 16, 2026 •

edited

Loading