EmailMessage should block `bcc` in `extra_headers` and docs should not suggest `bcc` is a header

[Natalia Bidart]

Following a security report deemed invalid, there are two related improvements to EmailMessage that we should pursue:

1. Add bcc to the extra_headers blocklist: EmailMessage.message() already blocks from, to, cc, and reply-to from being written into MIME headers via extra_headers, but bcc is missing.

2. Clarify docs to avoid saying that bcc is a "header": docs describe it as addresses used in the "Bcc header," which is inaccurate. Bcc addresses are passed to the SMTP server as RCPT TO recipients and never written into the MIME message -- there is no Bcc header in the outgoing message. The word "header" should be removed from that description.

[Mike Edmunds]

Replying to Natalia Bidart:

1. Add bcc to the extra_headers blocklist: EmailMessage.message() already blocks from, to, cc, and reply-to from being written into MIME headers via extra_headers, but bcc is missing.

Just to clarify, the check for from, to, cc, and reply-to ​in EmailMessage.message() is to avoid duplicating headers that have already been added earlier in that method. It's not really meant to be a general header suppression filter (although I suppose it could be).

This might need more discussion. It's true that a Bcc header does not belong in a message being handed off to SMTP, but there are some MTAs (e.g., sendmail -t) that do accept it. So there's a slight chance this could be a breaking change for some custom EmailBackend. Extremely slight, but thought I should mention it. (Also note the opposite request to add Bcc headers to serialized messages in the console and file backends, in #28598.)

[Mike Edmunds]

After some additional thought, I think the right way to handle this is for EmailMessage.message() to raise an error if it finds "bcc" in the headers. It's almost certainly a mistake on the caller's part, and we should be pointing them toward the bcc recipient arg instead. There's also a slight chance (per my earlier comment) it's deliberate. But either way, Django should not silently filter "bcc" out of the headers.

I would also probably mention this in the release notes as a potentially-breaking change without deprecation. (Any "working" code that depends on this is using undocumented, non-standard behavior for Bcc headers, so I think a breaking change is OK.)

[diaxoaine]

Replying to Mike Edmunds:

After some additional thought, I think the right way to handle this is for EmailMessage.message() to raise an error if it finds "bcc" in the headers. It's almost certainly a mistake on the caller's part, and we should be pointing them toward the bcc recipient arg instead. There's also a slight chance (per my earlier comment) it's deliberate. But either way, Django should not silently filter "bcc" out of the headers.

I would also probably mention this in the release notes as a potentially-breaking change without deprecation. (Any "working" code that depends on this is using undocumented, non-standard behavior for Bcc headers, so I think a breaking change is OK.)

Thanks, I updated the patch.

[nessita <124304+nessita@…>]

In 0943448:

Fixed #37152 -- Raised ValueError when Bcc is used in EmailMessage headers.

Bcc addresses are sent via the SMTP envelope and must never appear in
the message itself. A "Bcc" key in extra_headers was not excluded like
From/To/Cc/Reply-To, so it leaked into the generated message as a
visible header.

Thanks Mike Edmunds for reviews.

[Natalia <124304+nessita@…>]

In dd4e1a4:

[6.1.x] Fixed #37152 -- Raised ValueError when Bcc is used in EmailMessage headers.

Bcc addresses are sent via the SMTP envelope and must never appear in
the message itself. A "Bcc" key in extra_headers was not excluded like
From/To/Cc/Reply-To, so it leaked into the generated message as a
visible header.

Thanks Mike Edmunds for reviews.

Backport of 09434486302078c3649e034dfa74cf3f102db20b from main.