Multiple recipients with a separate email is really hard, causing data leaks #913
Labels
difficulty: unknown or n/a
fix is unknown in difficulty
status: help wanted
requesting help from the community
type: community enhancement
feature request not on Twilio's roadmap
We're using the library to send a single template, with substitutions, to many recipients. They should not get each other's information thus we don't want a single email with everyone in the To/Cc field. We've used v5 of the library with success, however, since v7 of the library there's a bug in the usage of the
Personalization
object. We had to change our implementation due to this and made a mistake in this change which has caused a data leak of our customers.We now found a safe way to do this in v7, but this is not a very common way and most other ways to do this leak data or don't send a correct email.
There's a few different methods we know of:
Mail->addPersonalization()
(see https://gist.github.com/lode/1daed164c0d5897be4ff8a1feadb0ce0#file-1-md)Mail->addTo()
withTo->setSubstitutions()
(see https://gist.github.com/lode/1daed164c0d5897be4ff8a1feadb0ce0#file-2-md)Mail->addBcc()
withBcc->setSubstitutions()
(see https://gist.github.com/lode/1daed164c0d5897be4ff8a1feadb0ce0#file-3-md)Mail->addPersonalization()
but usingMail->addTo()
withTo->setSubstitutions()
for the first recipient (see https://gist.github.com/lode/1daed164c0d5897be4ff8a1feadb0ce0#file-4-md)A fix for the bug in 1 was made in #705 half a year ago. However, no release has been issued since.
It would be great if we can get a release ASAP for this fix.
Next to that the usage patterns of 2 and 3 should be improved. Either the library should actually use different personalizations including correct substitutions. Or it should thrown an exception when trying to use substitutions for the
addTo()
/addBcc()
methods.I think on top the library could be improved in its architecture and coding standards. I've been diving into the code a little and find it very hard to find out what actually happens when using these different methods. Like how and when the Personalization objects are created. Right now the only way to discover the outcome is to adjust the API host and test the output of the API call. Cumbersome at least. Also it seems nowhere are there any checks on data integrety, causing the issues of 2 and 3. If this is all improved, I'd love to be able to call a method like
Mail->willUseSeparateEmailsForAllRecipients()
to verify that our usage is correct in automated processes and unit tests.The data leak we had is our own fault. But it would help a lot if the library is less buggy and has more safe guards to do things right. This unclarity of how to do it properly is affecting multiple customers, see #568, #629, #686, #849, #856 (comment), #882.
I love to hear and help out where possible!
The text was updated successfully, but these errors were encountered: