[Django] #28598: Django ignores BCC in console and filebased EmailBackend
#28598: Django ignores BCC in console and filebased EmailBackend
Reporter: zngr | Owner: nobody
Type: Uncategorized | Status: new
Component: Core (Mail) | Version: 1.11
Severity: Normal | Keywords: mail, bcc
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
we noticed during development that the bcc header line is not printed in
the console (and filebased since it inherits from console) EmailBackend
seems like this issue has been reported before, e.g. in #18582, however
there was no specific solution. It looks like a design decision, however
there is no documentation (that I found) about it.
In my opinion, it would be nice to have the BCC line printed in those
backends. As the documentation says, those backends are not intended for
use in production, which makes it an ideal tool for development and
testing. However that requires that the backend behaves just as a regular
(smtp) backend would and display the email message exactly as it would
have been sent.
If you decide not to fix this, please add a note to the documentation to
help developers avoid a sleepless night because they really can't get BCC
to work in their mail function ;)
What we display is the MIME message that the end-user receives, BCC is
passed in the RCPT TO command to the SMTP server. I can't think of a
decent way to include that as well so I'm going to just document the
I thought about including `message.recipients()`, my hesitation is that it
will double up the `From` and `CC` pieces since currently we show the MIME
which already includes that component. I wonder if adding
`.format_message()` isn't a case of YAGNI or over engineering.
I do agree that the proposed documentation patch is ugly, it makes
specific call outs to technical details that don't feel necessary.
What do you think about also documenting the fact that `filebased`
inherits from `console`? Having to double up docs is unfortunate.
Currently `write_message` also includes `'*' * 79`, is that part of the
overridable interface as well in your solution?
> I wonder if adding .format_message() isn't a case of YAGNI or over
Well, I guess most people won't need it, but that this ticket exists
suggest some will. Adding a hook to allow subclassing at least allows
those people to address their issue.
(Just saying in the docs that "BCCs won't be included" isn't great IMO: it
offers me no way forward.)
> ... it will double up ...
I wouldn't worry about this. If people want to do some set operations in
their subclass to get **just** the BCCs then they're welcome to.
All we're doing is providing the hook.
> Currently write_message also includes '*' * 79...
I'd leave that where it is. If someone wants to override `write_message()`
as well then they're welcome.
> ...write_message takes in an EmailMessage, not a string.
Yes, that's right. So they'd need to be some adjustment.
The trouble with `write_message()` as the hook is that you need to
essentially reimplement it (or copy and paste the whole thing) in order to
adjust the formatting.
As such it's more of a `wontfix` solution.
The idea I'm trying to communicate is that we add a `format_message()`
hook, which does just that, separate from the existing `write_message()`
method, which we just be responsible for the `write()` calls, message
I have a cursory implementation of your solution which is simple enough.
My hesitation is that this and the other opened issue seems more like
users wanting to ensure that their code is doing precisely what they are
telling it to do and then not realizing that BCC is not included in the
actual MIME text which is what we are printing
([https://github.com/mattupstate/flask-mail/pull/119 I speak from
experience]). Or that they want to be able to access it and expect to see
''everything'' since these backends are explicitly for development.
How about we add the hook and document BCC explicitly or that the default
implementations return the MIME text?
The no-BCC-in-MIME is very much part of the black box that is the email
spec which we shouldn't be reproducing in the docs but it is confusing
when encountered in this context.
Right. OK. I think you might have convinced me. :-)
What's your thought here: are you keen to add the (small?) amount of
set logic needed to calculate the BCC list and add that to the formatted
message for these backends?
Is there any sort of backwards compatibility guarantee on the output?