To BCC or not to BCC – that is the question data watchdog wants answered A data regulator has reminded companies they need to take care while writing emails to avoid unintentionally blurting out personal data. Unsurprisingly, much of the UK's Information Commissioner's Office (ICO) guidance comes down to the correct use of address fields for recipients and considering the content of an email before …
I'm not sure I'd say that it was misused, that seems to be unfairly stigmatising the BCC. It's more like they simply didn't use it, leading to the obvious information exposure.
I have the same thing at work. Email notification about stuff. Sent from somebody to somebody else, with dozens of names in the CC field (including some personal addresses for people like me who don't have a work account).
I did try to "educate" them, so the response was to mail me separately...when they remembered. So I gave up, and am happy that I gave them a specific email address.
This sort of thing should be mandatory training for everybody that deals with email, especially in these GDPR days...
"You cannot misuse the BCC field."
Of course you can, by BCCing the competition when reporting to The Board that MegaProject has just slipped another calendar quarter, for example.
I'll leave it as an exercise for the reader to figure out why using the BCC instead of sending it under separate cover might work better for your NefariousPlan[tm].
You can abuse the BCC field - by simply using it. This report, and many more cases in the past (probably in the thousands), shows that trying to send bulk email using the BCC method is not safe, because it practically invites the user to mess up. By either not understanding the difference, of by clicking in the wrong field, or because they can't remember which is which.
If you have to send an email to many people, use a bulk email that was build for that purpose. BCC is a crutch that should have been deprecated a long time ago.
@damienblackburn
It's using the functionality it was specifically designed for. That's not misuse or abuse. Ditto for using email for spam. That society doesn't like it is a separate issue.
Like taxi drivers can hardly claim car owners are abusing them by using the functionality their cars give them.
> It's using the functionality it was specifically designed for. That's not misuse or abuse.
Hold still, I am just going to drive this nine-inch-nail through your leg and into you calf, using this great big hammer.
What? What?
I'm just using the hammer's functionality it was specifically designed for[1]. You can't complain about that.
[1] hitting things; the use of the nail[2] is entirely incidental to the argument
[2] though even the nail was specifically designed to join two things together - in this case, the leg bone is connected to the - thigh bone.
"This sort of thing should be mandatory training for everybody"
Mandatory training can still go in one ear and out the other without encountering a brain between the two. Email clients have a lot to answer for here as in other respects. They should default to using BCC rather than CC.
"Mandatory training can still go in one ear and out the other without encountering a brain between the two."
I certainly agree with that, however here where I am, if you screw up something that you've been trained how to do correctly, it can be used for disciplinary. Depends on how much you screw up / how high up the manglement you are / how much noise the screw up creates (thankfully we've not had a social media shitstorm to see how fast people get thrown under buses).
How fucking difficult is it for programmers to wrap a tiny sanity check around the "To/CC/BCC" fields in their shitty email "apps" to pause for a second if there are more than (say) 10 people in the field ?
"Your email appears to be going to more than 10 people, and may include more people on the BCC list. Do you wish to check before sending ?"
for example. With an additional flag to enforce it for more paranoid organisations.
Or or we waiting for Apple to fucking patent it ?
@JimmyPage
That sounds remarkably like a call for blaming someone else.
"It's not my fault" - the rallying cry for everyone who refuses to accept responsibility for their own actions.
This is a forum for IT professionals not a reddit board for screaming abuse at others - maybe you could could write the first "unshittified" email app...
Mail shots going to large numbers of people (i.e. external customers) should really use something like MailChimp, or even some kind of Excel to Outlook merge. That means the e-mail only ever goes to one person at a time and you can't know who else has received it.
However this would be much less practical for internal corporate comms, in which cases internal training is key.
There's a very simple mechanism for bulk mailing -- locally hosted distribution lists, which absolutely ensure that each email lists only its single recipient in its headers. Using services such as mailchimp merely hands the recipient list to a third party that may or may not be trustworthy (and you can't find out), and when such services leak, they leak very seriously.
The source of the whole issue is twofold. On the one hand, distribution is left to informal processes conducted by the uninformed (CC instead of BCC) and on the other, we've been persuaded that third parties are more convenient to use than doing (essentially simple) tasks ourselves (e.g. mailchimp). Neither is a good idea if you want control over the results.
But there lies a third snag. Corporate risk assessment is almost exclusively focused on risk to the organisation. Risk to third parties (including clients) hardly registers if at all, so there's little incentive to ensure leakages such as the one reported don't occur. So roll on sloppy practices as they're less effort and cheaper to conduct.
>> should really use something like MailChimp,
> Using services such as mailchimp merely hands the recipient list to a third party
Something LIKE MailChimp, not ACTUALLY MailChimp!
Whatever happened to organisations running simple mail lists handlers internally?
And, no, "running mail lists internally"" does NOT mean you need to set up yet another web-based service on your Intranet and involve the DBAs in setting up it up (unless you want to); safe bulk emailing can start from running "blat" from a command line and work its way up to however GUI or webby you want it to be.
> How about something like Time & Chaos instead?
From their website: "Time and Chaos is the best CRM contact manager software for Windows users"
So, no doubt better than using Outlook (or *any* email client that is intended to be used by/for an individual's email), which is good.
OTOH, "CRM contact manager" sounds like it is going to try and do more than mailing lists.
Overall: good to have a suggestion, thank you. Now, has anyone else got anything equally PRACTICAL to add to the discussion? Any actual knowledge of another bit of software that can do the mailing list thing and just get away from all the pointless prattle about BCC?
If training could help then it would have done by now.
"Are you sure" doesn't achieve anything, not one of us can say that we don't click the OK button out of muscle memory. Even if you didn't click automatically, you are sure right up until the Ohno second when it becomes clear that you shouldn't have been.
It needs to be a UI issue. No mail client to accept more than one address in 'To' and the CC field to be at least two clicks further away than BCC.
But CC should be used much more often than BCC. It's only courtesy to let people know who else is privy to your communication.
For instance, my kids' school keeps emailing me and spouse about whatever they think we need to know. I am glad to see both our addresses in the To: field, it saves a whole layer of extra communication and confirmation.
The only time BCC is appropriate is - actually, when exactly? All the use cases I can think of would be better handled by a mail merge.
No. Why would you think that?
It sends emails saying things like "Swimming lessons start next Tuesday, so make sure [kid] has their kit". Or "[Kid] will be receiving a certificate at assembly on Friday". And the only names in the To: field are self and spouse, so I assume someone knows how to mail merge.
"It's only courtesy to let people know who else is privy to your communication."
I have used BCC for that.... Received: "Can you do X for me?" Me: "Department Y can do that." BCC: manager.dept.y. Another thing I do is mention emails during a face to face meeting. CC-ing people because they are referenced in the body invites Reply All madness.
Training does help, improved UI does help, but if there is zero tolerance for errors then only approved users should be able to send to external emails at all, regardless of how many recipients. I rather liked it when this lockdown was put into effect here. One less potential mistake I needed to fret over, no more requests "can you send an email to...", one less annual training to take. If mistakes were made I wasn't on the list of usual suspects. The highly competent administrative assistants know all the tools to handle bulk emails whether inside or out. It turns out I can still send bulk emails inside, but having seen some poor results when untrained people try, I don't go there.
@yetanotheraoc
Approved (trained) users in my organisation still manage to email the site distribution list by mistake.
Who knows if they're making mistakes with bcc / cc - they certainly wouldn't. Recipients are only likely to provide feedback after the damage has been done, and even then only if they are personally affected.
Had some emails come in recently where I was BCCed in on a hybrid exchange system. I don't know if they screwed it up, or this is default, as we don't use any hybrid setups, we are either on prem, or hosted o365.
But when I looked at the header of the emails, I found the exchange system had put all the BCC addresses in a field, apparently to pass it to the external exchange side, that didn't strip it out.
So every BCC email we have had like this has had the BCC address list 'hidden' in the headers for anyone to see all the people it was sent too!
Stop looking at email headers and other sophisticated data breach hacking activities or Mike Parson will have to take legal action.
Quote: ' "Email," said the ICO, "has increasingly become the default choice for efficiently sharing information, but this doesn’t always make it the best choice." '
Yup...also efficient for sending encrypted private material, mostly anonymously:
(1) Anonymous mailing address (e.g. from gmail.com)
(2) Burner phone required by gmail.com....irritatting!
(3) App password from gmail.com (so an application can send and receive)
(4) Private encryption (ref: Diffie/Hellman)
(5) Send or receive email
(6) Rinse and repeat at step #1
I mention this because ordinary citizens DO NOT HAVE TO TRUST WhatsApp or Signal and their well known E2EE.
Did I mention trust?
P.S. Regarding item #4, notice that EVERY message has a new, unused, randomly chosen key for encryption, a key that is destroyed after use.
When the economic value of critical infrastructure approaches negligible, whilst the functional value remains high, often due to the apparent simplicity of the tools, there are no incentives to provide training, investment in fundamental, incrementally small improvements so we’ll continue to languish in this mess of our own making.
Or we could do something about it. gov.uk, time to take the lead?
—Shazza DuPrés —
This is been a problem since email was invented. It seems strange that the ICO is only just mentioning it now.
A common response to such a message is to hit "reply all" and explain in no uncertain terms how incompetent the sender is, and why you will not be doing any further business with them.
Bonus points for making reference to their parentage, choice of sexual partners and deplorable personal hygiene.
why it's called carbon copy
Because of a folk etymology.
Carbon Copy (CC) and Blind Carbon Copy (BCC) fields
This is a myth. The abbreviation "cc" for "copies to" on memoranda was in use well before carbon paper was invented. Repeating an initial letter to indicate a plural in an abbreviation is long-established English usage, for example in "pp" for "pages".
The "Cc:" header field is an abbreviation for "copies", not for "carbon copy".
Interestingly, perhaps, in RFC 733 (et seq), Crocker does not use the term "carbon copy", merely describing the CC header as describing "secondary" recipients; but does incorrectly describe BCC as "Blind carbon". Neither CC nor BCC appeared in RFC 561; they're described in RFC 680, which (correctly) does not use the word "carbon". RFC 724, which updated 680, also avoids "carbon", so the error appears to have been introduced by Crocker in 733.
(And, yes, I've used carbon paper.)
"(And, yes, I've used carbon paper.)"
Remember "bursting" print jobs? How about jobs that included carbon paper copies? Doing this job manually, one would get thoroughly coated in ink/carbon. Invariably, I would manage to get fairly bad paper cuts in the web between my left thumb and index finger. To this day, I have a "smudge" tattoo in that location.
Have an upvote for the research (unless you asked ChatGPT to do it for you - nah, it looks too plausible for that... but then again, ChatGPT can appear to emit plausible stuff).
Maybe it refers to the idea that if enough copies are made and find their way into landfill, eventually they will turn to carbon.
I've just received input from several elderly family members who worked in typing pools in the 1940s, '50s and '60s.
All six of them report that cc: was "Courtesy Copy", and always in lower case, with the colon. Carbon paper was used occasionally for the secondary copies, but everybody hated it because it rubbed off and made a mess of everything ... and one could only make a couple copies at a time with carbon paper.
BCC was very rarely used, and then usually only scrawled (IN CAPS, no colon) on a cover sheet at the whims of the Boss. "BCC file cabinet" meant "type an extra copy for our records" and the like. The use of BCC skyrocketed when IBM et al made it easier for a "normal" typist to make multiple copies of a memo/letter/whathaveyou. So did the use of file cabinet space. The "B" stood for Blind, even back then.
The widespread use of electronic mail caused all this stuff to mutate slightly, to what we have now.
Note that all of the above Aunties and one Uncle were in the aerospace industry here on the West Coast of America, and is a small sample in the great scheme of things. Some folks may have had other experiences in other places and industries.
There are VERY few cases where you want to include 100 let alone 1000 addresses in the To or CC fields.
An email client could set a reasonable default like 20 (which could be increased by the user if necessary) for number of addresses added to the To or CC fields when originating or replying to an email, including list expansion. If exceeded, it will warn the user before sending "this message has nnn addressees in the CC field where they will be visible to recipients potentially compromising their privacy, would you rather use the BCC field to hide them?" Maybe the default for internal recipients would be larger (we've all been on ridiculous email chains with far too many people cc'ed) and the default for external recipients would be even smaller like 10.
That wouldn't solve all such issues, but it would probably eliminate the vast majority.
Another thing that could be done is to avoid automatic list expansion in both clients and servers - if addressees abc@foo.com and def@foo.com are part of the list xyz-list@foo.com then when they receive a message to that list they'd just see xyz-list@foo.com in the CC line (maybe the server needs to include their email address as well in case they may not realize they are part of that list...) so they won't know each other are part of that list. That keeps the distribution list private even when used in a CC or To line without impacting anyone's ability to reply to the message and have the full list see it. This is always done with mailing list software but doesn't seem to be the default for a standard email client, at least I see expanded lists too often. Since email clients don't always know the expansion of a list when checking the above default of 10 or 20 this mitigates the issue by treating the list as a single entity.
... at some of the proposed usage patterns here.
To: is for the primary recipients. You probably expect some action from them and/or a response.
CC: is for secondary recipients. You don't necessarily expect any action from them or a response but consider that the message is useful information to them, especially if they are directly mentioned. This is a courtesy, as is the fact that the principal recipients can see that they also got it.
BCC: is for, I dunno, snitching on your colleagues? Sharing confidential information with persons who shouldn't get it? Some other random nefariousness? Seems pretty shitty to me.
If you are just sending out a bulk mailing and don't want to leak PII then you need a program intended for that, not a personal email client.
-A.
Bcc:
When giving a junior with a different reporting structure some advice or instructions I might Bcc his or her manager without upsetting the person so that the manager is better informed with regards training needs and the capabilities of the junior and indeed what their report is doing. Occasionally exposes some toe rag offloading their assigned tasks onto the newbie. If that is nefarious I can wear that cap.
I can see that Cc: and Bcc: are pretty opaque to the post carbon paper generations so perhaps MUAs should present something like-
To:
Also to (recipients see):
Also to (hidden):
A lot of IT environments with a large proportion of millennials don't use email internally but rather messaging and video conferencing almost exclusively. I don't know whether this is a cause or an effect but there is a fairly high level of functional illiteracy amongst these youths. I hate to think what their documention is like.
Wasted more time than would have liked trying to make the case that a coherent (literate?) email exchange constitutes a valuable record that can be the basis of more formal documentation.
A lot of NHS community type stuff (such as a diabetes group I am signed up for on behalf of my mother) is now done on a voluntary or semi voluntary basis. About 2 or 3 times a year i get one where the lady running it has used CC instead of BCC, and she has to report herself each time. You may be inclined to blame the user, but she's an elderly volunteer. I blame the organization that hasn't provided her with foolproof tools to do the job.
> . I blame the organization that hasn't provided her with foolproof tools to do the job.
True - but, on the other hand, where have all the decent mailing list systems gone?
Every time I suggest looking at using a specialised mailing list tool, the response is "we can already that in Outlook".
With the results reported here.
...to placing confidential information in emails that aren't encrypted and can be viewed as they flow through servers on their way to their destination.
You mean like Law firms and Finance companies do, EVERY DAY OF THE YEAR.
What is the chocolate teapot regulator doing about it? Watching from the sidelines.
> What is the chocolate teapot regulator doing about it?
How often are you sending in (non-ranty) suggestions about this to the regulators? Who is your contact there, so that we can all send them a message and (politely) agree that this is something they should have been working on?
Seriously?
We have nothing better than to fine an NHS body?
No matter how much - certain people - want to move the NHS to a fully-commercial status, it isn't (yet) entirely owned by shareholders who are going to raise a fuss when that fine comes out of their dividends.
So where is that money going to come from to pay the fine? What is going to get cut to make up the shortfall?
And so are mailing list servers, from Majordomo to Mailman to ...
They are specifically designed to handle bulk emails, and can be configured to hide the sender's address as well as all the list members. The [l]user cannot make a mistake.
I (IT geek) got accused, via reply to all, of' 'unprofessional behavior' when I used 'reply to all' to an email to 2,000 employees from HR. Replied, via 'reply to all' that HR should have used BCC for the original email and included a link to the relevant RFC.
Got hauled in front of a disciplinary meeting...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
