Blind Carbon Copy Myths and Realities

From Messaging Server Technical Reference Wiki
Jump to: navigation, search

The term "blind carbon copy" originated in the days of manual typewriters when multiple copies of interoffice memoranda were created using carbon paper. Up to five or six copies could be made at once (as long as the paper was thin enough to fit in the typewriter). At some point somebody had the idea of making an extra copy and giving it to someone not on the recipient list and the blind carbon copy was born.

An added fillip in this process became to add a "bcc" line to the blind carbon indicating its status, either by sticking the copy back in the typewriter or by simply writing it in by hand.

The blind carbon idea was so popular that users wanted it in email. However, it is incorrect to say that email was specifically designed to provide the construct. It didn't have to be: The fact that in email the header is distinct from the envelope makes it possible to send mail to recipients without any mention of them in the header, and that's sufficient to implement blind carbons.

The parallel with paper correspondence actually goes even further: The To:, Cc:, and Bcc: header fields are, contrary to the understanding of many, simply an optional means of informing recipients of their status, in the same way adding a "to", "cc" or "bcc" line was in a paper memo. The presence of a recipient's address in a To: or Cc: field is an indication the message was not indended to be a blind carbon while the presence of a Bcc: field is an indication that the message is a blind carbon. The absence of a Bcc: field brings this discussion to the first blind carbon myth:

Myth: The absence of a Bcc: field means a message is not a blind carbon.

Reality: Use of a bcc to indicate a blind carbon forces the user agent to submit the message at least twice, once without the Bcc: field for all normal recipients and once with an appropriate Bcc: field for each blind carbon copy recipient. (Note that some agents generate a single copy for all blind carbon recipients and a Bcc: field listing all of them, but this has the effect of making all blind carbon recipients aware of each other, which may not be appropriate. And two submissions are still required.)

Some user agents prefer not to go to the extra effort to perform multiple submissions and instead simply include the blind carbon recipient in the message envelope but omit that recipient from the message header. As such, the absence of a Bcc: field cannot be used to determine a message's blind carbon status.

But things don't stop there...

Myth: The absence of a recipient's address from a To: or Cc: field can be taken as an indication that a message is a blind carbon.

Reality: The absence of a recipient's address from the header can arise in many ways besides blind carbons. Probably the most common case is a message from a mailing list: Here the list address probably appears but not the addresses of the list members. And while some mailing list messages can be identified as such, it is in general not possible to determine that a message originated from a list.

Another common case is where a message is automatically forwarded from one domain to another. Autoforwarding often doesn't alter the message header, so the header ends up with the "old" address for the recipient while the envelope ends up with the "new" one. And once the message leaves the autoforwarder's administrative domain it is no longer possible to reliably correlate the two addresses.

In conclusion, while the presence of a recipient's address in the message header conveys information about the indended status of that recipient, the absence of that recipient's address cannot be used to determine a recipient's status.