Skip to content

fix: use RFC 2231 encoding for non-ASCII attachment filenames #502

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
taylorwilsdon merged 3 commits into from
Feb 24, 2026
Merged

fix: use RFC 2231 encoding for non-ASCII attachment filenames #502

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
0dc9985
fix: use RFC 2231 encoding for non-ASCII attachment filenames
stakeswky Feb 23, 2026
2526b87
fix: also strip null bytes from attachment filename for consistency
Feb 23, 2026
252487f
Apply suggestions from code review
taylorwilsdon Feb 24, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 9 additions & 6 deletions gmail/gmail_tools.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -327,17 +327,20 @@ def _prepare_gmail_message(
part.set_payload(file_data)
encoders.encode_base64(part)

# Sanitize filename to prevent header injection and ensure valid quoting
# Use add_header with keyword argument so Python's email
# library applies RFC 2231 encoding for non-ASCII filenames
# (e.g. filename*=utf-8''Pr%C3%BCfbericht.pdf). Manual
# string formatting would drop non-ASCII characters and cause
# Gmail to display "noname".
Comment on lines +332 to +334

Copilot AI Feb 24, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The comment states that manual string formatting "would drop non-ASCII characters", but more accurately, it embeds them as raw bytes that Gmail cannot parse. Consider updating the comment to:

"Manual string formatting would embed non-ASCII characters as raw bytes, which Gmail cannot parse and causes it to display 'noname'."

This is more technically accurate about what's happening.

Suggested change
# (e.g. filename*=utf-8''Pr%C3%BCfbericht.pdf). Manual
# string formatting would drop non-ASCII characters and cause
# Gmail to display "noname".
# (e.g. filename*=utf-8''Pr%C3%BCfbericht.pdf). Manual string
# formatting would embed non-ASCII characters as raw bytes,
# which Gmail cannot parse and causes it to display "noname".

Copilot uses AI. Check for mistakes.
safe_filename = (
(filename or "")
(filename or "attachment")
.replace("\r", "")
.replace("\n", "")
.replace("\\", "\\\\")
.replace('"', r"\"")
)
.replace("\x00", "")
) or "attachment"

part.add_header(
"Content-Disposition", f'attachment; filename="{safe_filename}"'
"Content-Disposition", "attachment", filename=safe_filename
)
Comment on lines +330 to 344

Copilot AI Feb 24, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The attachment handling logic, including the RFC 2231 encoding fix for non-ASCII filenames, lacks test coverage. Consider adding tests to verify:

  1. Non-ASCII filenames are properly encoded (e.g., "Prüfbericht.pdf" produces filename* header)
  2. ASCII-only filenames remain unchanged
  3. Edge cases like filenames with control characters
  4. Filenames that become empty after sanitization

This is important to prevent regressions of the fix for issue #500.

Copilot uses AI. Check for mistakes.

message.attach(part)
Expand Down
Loading