fix: RFC 2047 encode non-ASCII display names in address headers#405
fix: RFC 2047 encode non-ASCII display names in address headers#405HaseU-git wants to merge 1 commit intogoogleworkspace:mainfrom
Conversation
…leworkspace#404) Apply encode_address_header_value() to To, From, Cc, and Bcc headers in MessageBuilder::build() so that non-ASCII display names (e.g. Japanese characters) are properly RFC 2047 encoded. Previously only the Subject header was encoded, causing mojibake in address headers. Closes googleworkspace#404 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: bd170fa The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
googleworkspace-bot
added
the
area: core
|
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. |
Summary of ChangesHello, I'm Gemini Code Assist1! 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 resolves an issue where non-ASCII display names in email address headers were not being properly encoded according to RFC 2047, resulting in garbled text (mojibake) when emails were viewed in certain clients. The changes introduce a dedicated function to handle the encoding of display names within address headers and apply it consistently across all relevant email fields, ensuring international characters are correctly preserved and displayed. Highlights
Changelog
Activity
Using Gemini Code AssistThe 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
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 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. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request aims to correctly implement RFC 2047 encoding for email address headers by introducing the encode_address_header_value function, applying it to To, From, Cc, and Bcc headers. While a security audit confirmed no high or critical severity vulnerabilities, a critical issue was identified in the parsing logic of encode_address_header_value. The current implementation uses a simple string split on commas, which can lead to malformed headers for email addresses with commas in quoted display names. This requires a fix by reusing existing robust parsing logic and adding a unit test.
| pub(super) fn encode_address_header_value(value: &str) -> String { | ||
| value | ||
| .split(',') | ||
| .map(|addr| { | ||
| let trimmed = addr.trim(); | ||
| if let Some(open) = trimmed.rfind('<') { | ||
| let display = trimmed[..open].trim(); | ||
| let angle_addr = &trimmed[open..]; // "<email>" | ||
| if display.is_empty() { | ||
| trimmed.to_string() | ||
| } else { | ||
| // Strip surrounding quotes if present. | ||
| let unquoted = display.trim_matches('"').trim(); | ||
| format!("{} {}", encode_header_value(unquoted), angle_addr) | ||
| } | ||
| } else { | ||
| // Bare address (no display name) — nothing to encode. | ||
| trimmed.to_string() | ||
| } | ||
| }) | ||
| .collect::<Vec<_>>() | ||
| .join(", ") | ||
| } |
There was a problem hiding this comment.
This function incorrectly uses .split(',') to parse a list of email addresses. This will fail for valid addresses where the display name contains a comma inside quotes, such as "Doe, John" <john@example.com>. This is a critical bug that can lead to malformed headers and email delivery issues.
The codebase already has a correct implementation for this in src/helpers/gmail/reply.rs: the split_mailbox_list function. It correctly handles quoted strings. I strongly recommend refactoring to use that logic here. This would likely involve moving split_mailbox_list to this shared mod.rs file to make it accessible.
Here's how the corrected function could look after making split_mailbox_list available:
pub(super) fn encode_address_header_value(value: &str) -> String {
split_mailbox_list(value) // Use the robust splitter
.iter()
.map(|addr| {
let trimmed = addr.trim(); // addr is already a single, complete address
if let Some(open) = trimmed.rfind('<') {
let display = trimmed[..open].trim();
let angle_addr = &trimmed[open..]; // "<email>"
if display.is_empty() {
trimmed.to_string()
} else {
// Strip surrounding quotes if present.
let unquoted = display.trim_matches('"').trim();
format!("{} {}", encode_header_value(unquoted), angle_addr)
}
} else {
// Bare address (no display name) — nothing to encode.
trimmed.to_string()
}
})
.collect::<Vec<_>>()
.join(", ")
}Additionally, please add a new unit test to cover this comma-in-display-name scenario to prevent regressions.
#[test]
fn test_encode_address_header_value_quoted_comma_in_name() {
let input = r#""Doe, John" <john.doe@example.com>, "Smith, Jane" <jane.smith@example.com>"#;
let result = encode_address_header_value(input);
// The exact assertion depends on how encode_header_value handles ASCII,
// but the key is that it shouldn't split the names.
assert!(result.contains("Doe, John <john.doe@example.com>"));
assert!(result.contains("Smith, Jane <jane.smith@example.com>"));
assert_eq!(result.matches(", ").count(), 1, "Should only be one separator between addresses");
}2 participants
Description
Non-ASCII display names in To, From, Cc, and Bcc headers were not RFC 2047 encoded, causing mojibake when the draft was viewed in Gmail (e.g. Japanese
下野祐太appeared asä¸‹é‡Žç¥ å¤ª).The root cause was that
MessageBuilder::build()appliedencode_header_value()(RFC 2047) only to the Subject header, while address headers used onlysanitize_header_value()which strips CRLF but does not encode non-ASCII characters.Changes
encode_address_header_value()— parses address formats ("Name" <addr>,Name <addr>, bareaddr, comma-separated lists), encodes only the display-name portion via RFC 2047, and preserves the angle-bracket email address as-is.encode_address_header_value()to To, From, Cc, and Bcc inMessageBuilder::build().encode_address_header_value()(bare email, ASCII display name, non-ASCII display name, multiple addresses, unquoted non-ASCII).test_message_builder_non_ascii_address_headersverifying all four address headers are properly encoded.Closes #404
Checklist:
AGENTS.mdguidelines (no generatedgoogle-*crates).cargo fmt --allto format the code perfectly.cargo clippy -- -D warningsand resolved all warnings.pnpx changeset) to document my changes.