Closed dgilmanAIDENTIFIED closed 6 days ago
Thanks for the report. This is probably something that belongs in Anymail's Mandrill docs under "Limitations and quirks."
Mandrill seems to have an account-level setting "Expose The List Of Recipients When Sending To Multiple Addresses" which controls this.
You can also override the setting for individual (non-batch) messages using Anymail's esp_extra
:
message.esp_extra = {
"message": {
"preserve_recipients": True
}
}
Or for all (non-batch) sends using Anymail's global send defaults:
# settings.py
ANYMAIL = {
...,
"MANDRILL_SEND_DEFAULTS": {
"esp_extra": {
"message": {
"preserve_recipients": True
},
},
},
}
If you use merge_data
or another option that enables batch send mode, Anymail forces preserve_recipients
to False, because the to
recipients in a batch send aren't supposed to be visible to each other. This will override any other options or account-level defaults.
Incidentally, I think Mandrill used to apply ccs and bccs independently of preserve-recipients. I'm pretty sure they used to get copied on each message resulting from a batch send, one per to
recipient customized with that to
's merge data. (Because I'm pretty sure that's what Anymail's predecessor package Djrill used to do, and Djrill was a very thin wrapper around the Mandrill API. But I might be remembering wrong.)
It appears that Mandrill is by default rewriting Bcc: to To: and delivering separate emails. It seems a common enough problem that there are several online discussions brought up by a Google search but also a FAQ entry on their website: https://www.courier.com/error-solutions/mandrill-bcc-not-working/
The root of the issue appears to be that django-anymail is correctly setting the type (in the API request) as
bcc
but also needs to passpreserve-recipients: true
to get a single email sent with bothTo:
andBcc:
emails on it. It is probably sensible to allow the user to configure this behavior on an email-by-email basis and to not change the current, default behavior.I'm opening this issue to grab the attention of any other Mandrill users who might have run into the issue. Right now I don't currently have the time to fully explore this and write a patch. However it doesn't look like an invasive change and I'll be glad to open that PR later if I can get it done myself.