-
Notifications
You must be signed in to change notification settings - Fork 1k
Description
Version
0.16.0
Affected commands
+send --cc, +send --bcc, +reply-all (auto-generated Cc), +reply --cc, +forward
Problem
Cc/Bcc headers are appended after MIME-Version and Content-Type in the raw RFC 2822 message. Gmail's API does not process addressing headers that appear after the MIME block, so CC/BCC recipients never receive the email — even though the headers appear correctly in the sent message metadata.
Reproduction
gws gmail +send --to alice@example.com --cc bob@example.com --subject 'test' --body 'test' --dry-run
# Decode the base64 raw field:Current header order:
To: alice@example.com
Subject: test
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: bob@example.com <-- placed after MIME headers
Same issue with +reply-all:
gws gmail +reply-all --message-id <id> --body 'test' --dry-runTo: sender@example.com
Subject: Re: Original subject
In-Reply-To: <id@example.com>
References: <id@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Cc: you@example.com <-- placed after MIME headers
Expected header order
Addressing headers (To, Cc, Bcc) should be placed before MIME headers:
To: alice@example.com
Cc: bob@example.com <-- before MIME headers
Subject: test
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Impact
All CC/BCC recipients silently don't receive emails. The headers appear in sent message metadata, making it look like delivery succeeded.
Note
The v0.16.0 RFC 2047 fix (c61b9cb) correctly encodes non-ASCII display names in Cc/Bcc but does not address the header ordering. The --cc/--bcc flags added in v0.11.0 (4d4b09f) appear to append headers at the end of the header block rather than grouping them with other addressing headers.