Oops, that isn't good when a privacy policy rollout causes mass private info to get out.
They should have just sent the email one per individual user anyways for safety.
When you CC/BCC it spawns the copies downstream and can cause issues sometimes if there are too many.
Back in the day over dual ISDN lines, we used to update pharmaceutical machines with FTP and email back in late 90s and when we BCC'd the backup updates (machine tried to connect FTP then looked for email updates to update itself) the ISPs would get mad at us as it hosed their systems a few times due to the number per message.
Depending on the volume and sensitivity, it is sometimes better just to send one per user not only for privacy/protection but for cpu/memory reasons up or downstream.
As far as I remember, (B)CC is implemented by just setting multiple RCPT headers in the SMTP envelope, and for BCC not setting them in the DATA (email body)—surely then, the only difference with 1-envelope-per-recipient is less SMTP messages? If you implement the same level of rate limiting as you would have on 1-per, how could you ever cause more traffic / resource usage?
Do you mean it’s easier for humans to then not set those rate limits if you’re using multiple RCPTs?
At some point the CC/BCC messages duplicate per consumer even if it is on receive/pull.
Probably less of an issue now, but back then the ISP/provider would duplicate the sending of the messages with multiple recipients, could have just been a flaw at the ISP which was Frontier back then. Could have just been a DDoS type event where too many were pulling at once rather than throttled/tapered or spaced out over time. The group emails spiked their systems, probably not an issue today.
Personally though the cost of CPU/memory is small now, I wouldn't risk sending sensitive data to a large group unless I could verify BCC was being set not CC. Seems a small price to pay to not allow a mistake like that by duplicating the messages app side rather than provider side. By sending out throttled by user on app side, even if a developer or marketing person inadvertently chose CC rather than BCC, it wouldn't leak sensitive info (emails).
Could also be that if you send one message with 10k bcc, they all hit isp at once. If you send message per recipient, the isp will get a stream of messages.
I love asking why when I get these kinds of request so i can better understand the requirements. I’ve found that some people aren’t interested in helping you understand. I had a recent interaction with a surgeon who was vexed by me asking for more detail and why that reminded me that some people just want to do their job and don’t care about learning.
I urge you to reconsider if this comment adds anything to the discussion. "Less" vs "fewer" doesn't cause any ambiguity or confusion, (versus, say, 'literally' being misused) so I see no point in bothering to correct it.
I found that sentence difficult to understand, though. One problem was the use of "difference with" instead of "difference from", which can have the opposite of the intended meaning. I had to read it several times...
They should have just sent the email one per individual user anyways for safety.
When you CC/BCC it spawns the copies downstream and can cause issues sometimes if there are too many.
Back in the day over dual ISDN lines, we used to update pharmaceutical machines with FTP and email back in late 90s and when we BCC'd the backup updates (machine tried to connect FTP then looked for email updates to update itself) the ISPs would get mad at us as it hosed their systems a few times due to the number per message.
Depending on the volume and sensitivity, it is sometimes better just to send one per user not only for privacy/protection but for cpu/memory reasons up or downstream.