#747·himalaya

SMTP send transmits the Bcc: header to all recipients, exposing blind recipients

Author: aminamosCreated Sep 12, 2026Updated Sep 12, 2026

Version

himalaya v2.1.0 (build ca88bee08ad2e92127b46dc6200d1e8201885156, windows gnu x86_64)

Problem

message send derives the SMTP envelope from From:/To:/Cc:/Bcc:, but then transmits the raw message bytes unchanged as DATA. When the message contains a Bcc: header (for example produced by message compose --bcc ...), every envelope recipient receives that header, so all blind recipients' addresses are visible to each other.

Steps to reproduce

  1. himalaya message compose --to [email protected] --bcc [email protected] --subject test --body test > msg.eml — the composed output contains Bcc: <[email protected]>.
  2. himalaya message send < msg.eml (or ... | himalaya message send).
  3. Read the message as [email protected] or [email protected]: the delivered copy contains the full Bcc: line.

Verified against Gmail SMTP (smtp.gmail.com): all Bcc'd recipients received the complete Bcc: list in the delivered message.

Where it comes from

src/smtp/backend.rs::send_message collects forward paths from To:/Cc:/Bcc: and then calls self.send(reverse_path, forward_paths, raw) with raw untouched. There is no removal/blanking step, and no flag or config option to strip the header (message send --help, code search).

Expected

The Bcc: field should not be delivered to recipients (RFC 5322 §3.6.3 semantics): use Bcc: only for the envelope, then remove it from DATA (or blank it to Bcc: undisclosed-recipients:;). At minimum, warn or require an explicit opt-in.

Side note

message read hides Bcc: in its rendered header block (it shows only Date/From/To/Cc/Subject), which makes auditing a sent copy for this issue harder; --raw is required to see it.