I’ve just made this mistake of sending an e-mail to a few hundred people, revealing their emails to everyone else.
Usually we loop over the users and send a personalized email to each one of them, but for once the email was the same so I went with sending it once.
That’s why I did not even think about the fact that the emails would be visible to everyone.
The “fun” part of it is that I thought I was so clever to enhance performance by sending it only once.
Anyway, after having thought about my mistake I realized that most of the time when sending the same email to a bunch of people one would almost never want the emails to be visible to everyone.
The exception would be to allow people to reply to one another, like in some task management system, but again I think in the majority of cases one wouldn’t want that.
That’s why I think it’s best to be cautious by default, maybe by doing a BCC send by default unless some other option is provided (reveal_emails: true ?).
I think it would be a safe bet because if I’d like others to see the emails I most probably will notice while working on the feature that they are not visible by default.
The opposite is not true. Proof is I just totally forgot about this “side-effect”.
I don’t think anything should be changed to deal with the api personally. The options translate to how email works and to me that’s what makes the most sense. Ideally testing would have brought the “error” to your attention before it was used in production.
Ideally testing would have brought the “error” to your attention before it was used in production.
I think the point here was that the coder did not think if this problem. Adding a test for it would require thinking if it.
I do think it would be strange for bcc to be the default, though. The only alternative I can think of would be a small breaking change: if multiple recipients would be able to see each others’ emails, require setting an allow_recipients_to_see_each_others_emails flag. If not set, and multiple recipients are on to/cc, raise an error.
Sending a single email to multiple recipients is not really a winning strategy to defeat the spam filters in 2016 – like, maybe you can send an email to a small group of friends or colleagues, but past 20 or 25 people most SMTP servers actually reject the outgoing send when you try to send it. (And it will certainly flag your email and domain by spam filters).
I would suggest that because of this new reality – which wasn’t really the way the world worked in 2005 — the option should be re-thinked to allow_multiple_recipients which would default to false. If you pass more than 1 recipient and allow_multiple_recipients is false (or has defaulted to false), the Mailer would either warn or raise.
As this would be a breaking change something like this should probably warn for at least 1 version of Rails before it starts to raise.
This strategy works fine for everyone who already sends one-off emails and encourages people to move in that direction, and explicitly opt-out of that behavior if they want to retain the old functionality.
Ideally testing would have brought the “error” to your attention before it was used in production.
I think the point here was that the coder did not think if this problem. Adding a test for it would require thinking if it.
My parsing of the previous statement was that manual testing could have caught this - basic, “push the button and see what it does” kind of testing.
I don’t see the utility of a guardrail to prevent “bad” emails from being generated: people who understand the risks end up having to do a slight amount of additional ceremony, and people who don’t understand the risks copy-paste the incantation to “make it work”.
