BCC copy of outgoing mail never reaches Sent #504

New issue

Closed

opened 2026-09-09 21:29:52 +02:00 by johnsturgeon · 1 comment

johnsturgeon commented

2026-09-09 21:29:52 +02:00

Owner

Outgoing production mail is BCC'd to MAIL_FROM so a copy lands back in the pool mailbox, where a Fastmail Sieve rule keyed on X-TGFP-Autosave: sent files it into Sent. The copies are not arriving.

What was ruled out

The application code is correct. Verified against the tree that production was running (2.32.1) and the current release (2.33.0):

_send sets bcc=[config.MAIL_FROM] and headers={"X-TGFP-Autosave": "sent"} on every message, and every sender in the app routes through it — including the EmailQueue drain, via send_custom_email.
aiosmtplib's send_message turns the Bcc header into a real envelope RCPT TO and deletes the header from the transmitted copy (aiosmtplib/email.py:59). It is a genuine delivery, not a header-only ghost.
Dumping the prepared MIME message confirms both Bcc: and X-TGFP-Autosave: sent are present before handoff to SMTP.

So the app hands Fastmail a copy addressed to john@tgfp.us on every send. The loss is downstream.

Likely cause

MAIL_FROM is both the envelope sender and the BCC recipient. If Fastmail is saving submitted mail to Sent on its own, the inbound BCC copy carries the same Message-ID as the copy already in Sent and is dropped as a duplicate. That matches the symptom either way it falls out: one copy in Sent that looks like the Sieve rule worked, or none at all, and nothing in Inbox.

Unconfirmed — it needs checking in the mailbox, not the repo.

Confirm first

Open a message in Sent and view its raw source. X-TGFP-Autosave: sent present means the BCC arrived and the rule fired; absent means that copy is Fastmail's own auto-save and the BCC was dropped.
Fastmail's delivery log will show whether a RCPT TO: john@tgfp.us was accepted.
Disable "save a copy of sent messages" briefly and send one. If a copy still appears, it is the BCC.

Fix

BCC TGFP_ADMIN_EMAIL (john@sturgeon.me) rather than MAIL_FROM. A different mailbox from the sender, so there is no self-dedup and no dependency on the Sieve rule firing at all.

bcc=[config.TGFP_ADMIN_EMAIL],

One line in app/mailer.py. Both values already exist in config; no new secret.

Worth deciding at the same time: whether the BCC should keep going out from the development server, where it currently reaches the real mailbox regardless of the recipient rewrite added in #501.

Outgoing production mail is BCC'd to `MAIL_FROM` so a copy lands back in the pool mailbox, where a Fastmail Sieve rule keyed on `X-TGFP-Autosave: sent` files it into Sent. The copies are not arriving. ## What was ruled out The application code is correct. Verified against the tree that production was running (2.32.1) and the current release (2.33.0): - `_send` sets `bcc=[config.MAIL_FROM]` and `headers={"X-TGFP-Autosave": "sent"}` on every message, and every sender in the app routes through it — including the `EmailQueue` drain, via `send_custom_email`. - aiosmtplib's `send_message` turns the `Bcc` header into a real envelope `RCPT TO` and deletes the header from the transmitted copy (`aiosmtplib/email.py:59`). It is a genuine delivery, not a header-only ghost. - Dumping the prepared MIME message confirms both `Bcc:` and `X-TGFP-Autosave: sent` are present before handoff to SMTP. So the app hands Fastmail a copy addressed to `john@tgfp.us` on every send. The loss is downstream. ## Likely cause `MAIL_FROM` is both the envelope sender and the BCC recipient. If Fastmail is saving submitted mail to Sent on its own, the inbound BCC copy carries the same `Message-ID` as the copy already in Sent and is dropped as a duplicate. That matches the symptom either way it falls out: one copy in Sent that looks like the Sieve rule worked, or none at all, and nothing in Inbox. Unconfirmed — it needs checking in the mailbox, not the repo. ## Confirm first 1. Open a message in Sent and view its raw source. `X-TGFP-Autosave: sent` present means the BCC arrived and the rule fired; absent means that copy is Fastmail's own auto-save and the BCC was dropped. 2. Fastmail's delivery log will show whether a `RCPT TO: john@tgfp.us` was accepted. 3. Disable "save a copy of sent messages" briefly and send one. If a copy still appears, it is the BCC. ## Fix BCC `TGFP_ADMIN_EMAIL` (`john@sturgeon.me`) rather than `MAIL_FROM`. A different mailbox from the sender, so there is no self-dedup and no dependency on the Sieve rule firing at all. ```python bcc=[config.TGFP_ADMIN_EMAIL], ``` One line in `app/mailer.py`. Both values already exist in config; no new secret. Worth deciding at the same time: whether the BCC should keep going out from the development server, where it currently reaches the real mailbox regardless of the recipient rewrite added in #501.

johnsturgeon commented

2026-09-11 15:55:36 +02:00

Author

Owner

This was actually a mistake on the server side (imap server), it's all clear now

johnsturgeon closed this issue

2026-09-11 15:55:37 +02:00