Email musing: so, what are these P1 recipients then?

Have you heard of them? No? I’m not surprised, this is kinda technical stuff, but in what I was doing, this was essential. In a nutshell, P1 recipients (I’ll explain later why they’re called that) are the actual recipients of an email at any given staging point that the email, or one of its copies, goes through on its way to its destination(s). There, simple. You wouldn’t believe how many people didn’t get it (not you, I’m sure). More often, people confused them with Bcc recipients, but there’s a reason for that: a lot of people don’t understand Bcc recipients either.

You’ve all heard of To, Cc, and Bcc recipients, right? Well, at least the first two kinds? Let’s have a refresher:

‘To’ recipients are the names or addresses that you enter on the To line/box when you compose an email. These are the people (or whatever, e.g. shared mailbox info@wordpress.com) that you’re sending the email to, sending directly to.

‘Cc’ recipients, where Cc stands for Carbon Copy (from the good old days when you used carbon paper to make mutiple copies of a letter on a typewriter), are the people that you’re sending a ‘copy’ of the email to. They’re not directly concerned, you’re not ‘talking’ straight to them, but nevertheless you want them to know.

You’re also making implicitly clear, to anyone on the To or Cc list, of who else you’re overtly sending the email to. That’s because the To and Cc lists are part of the email’s content; they’re visible to anyone reading the received email.

Right, at least this distinction was the intention. I’m sure plenty of people never use Cc and just bundle everybody in To (or worse, bundle everybody in Cc and leave To empty), but the goal here was clarity: if you send an email to Bob and Alice, and write “Hi there, I thought you might want to go out on a date with me tonight”, you’d better be sure that you mean that you want both of them to come. It’s like good punctuation: it makes things clear. Now, if you wanted to ask Bob out, and just wanted Alice to know (and Bob to realise that Alice would know), you’d put Bob as a To, and Alice as a Cc. Bob would receive the email and realise that you’re asking him out, but also letting Alice know. Alice would receive the email and realise that it’s addressed to Bob, but that her name is clearly there in the Cc list, because you wanted her to know, and Bob to know that she would know. Keeping up?

What about Bcc recipients? Well, now imagine that you’re asking Alice out, and want to let Bob know, but without Alice realising. Simple: put Alice in To, and Bob as Bcc. Bcc stands for Blind Carbon Copy. ‘Blind’ because none of the other recipients (the To and Cc ones – Alice only in this example) knows that a copy of the message is going elsewhere; they are blind to it. This works because whatever you enter in Bcc never appears in the text of the received email, never ever. Whatever you enter in Bcc is like a command you give verbally while handing out a written message – it’s not written down.

But this is where confusion arises. Because once the mail is in transit nobody knows what the Bcc recipients were to start with, people imagine that any recipient that the email server knows about, but is not  listed in the email content itself as To or Cc, surely must be a Bcc recipient. Right? Nope. The thing is, To, Cc, and Bcc only mean something to you, the guy composing and sending the email. The email system itself, on the other hand, couldn’t give a hoot. Its job is to deliver the email to a list of recipients. That a recipient was a To, Cc, or Bcc recipient, is of no relevance – that fact only mattered to you.

So what are the P1 recipients then? Well, they are these recipients I just mentioned whose types the email system doesn’t care about… with a twist:

Let’s imagine, going back to our last example, that Bob works in the same company as you (“ACME”), and your boss is paranoid (let’s call him James) and wants a copy of every email you send. He bribed the email administrator to set up that rule. Alice, on the other hand, works for a different company (“RRLtd”), and no-one snoops on her emails. Both your company and Alice’s have basic journaling in place (where a simple copy of every email is kept in an archive).

This is where your email is actually going:
(Note: for the sake of simplicity, the following stages are not completely accurate.)

1. When you composed the email, you entered Alice as a To, and Bob as a Bcc.
   The P1 recipients at that point were simply Alice and Bob.
2. When you clicked “Send”, the email first got to ACME’s mail server, which promptly added your boss as a recipient, and also the journal mailbox (for archiving).
   Now your P1 recipients are Alice, Bob, James, and ACMEJournal.
3. Because Alice is in a different company, at that point the email ‘forks’: a copy of it goes to RRLtd, while another copy stays at ACME.
   The P1 recipients on the copy going to RRLtd are Alice – nobody else.
   The P1 recipients on the copy staying at ACME are now Bob, James, and ACMEJournal.
4. When the mail server at RRLtd receives the email for Alice, it adds RRJournal as a recipient (for archiving).
   The P1 recipients now on that copy of the email are Alice and RRJournal.

When James gets the email, he will see that you sent an email to Alice. He won’t know about Bob.

When Alice gets the email, she’ll only see herself as a recipient.

When Bob gets the email, he’ll see that it was sent to Alice, but won’t see himself as a recipient. If he’s smart, he will guess that you sent him a copy as a Bcc recipient.

The journals, they don’t really care, they’re not human, but if the email administrators of ACME and RRLtd have a look in their respective journal, they’ll simple see an email from you addressed to Alice.

So, as you can see, there were here lots of various lists of P1 recipients, depending on where the email was, and which copy it was. And as we saw, in all but the first stage this had little to do with who was actually entered as a Bcc recipient.

Why is it wrong to work out the Bcc recipients from the P1 recipients?

For two reasons: one, as I explained, Bcc recipients only mean something to you the sender; and two, you’d be asserting something that the sender didn’t actually set up(*):

At stage #2 above, if someone takes the P1 recipients and remove from the list any recipient that the email’s content says was a To or Cc recipient (itself a flawed process – maybe for another time), and then says “what’s left are the Bcc recipients”, then the Bcc recipients would be given as James, Bob, and ACMEJournal. But you didn’t enter James and ACMEJournal as Bcc recipients! Piffle? Well, if your company has a compliance policy that prohibits you sending emails to James, you’ve just been caught and labelled a traitor. Nice one.

(*) Again, except and only at exactly the first stage in the email’s travels, when P1=To+Cc+Bcc.

Conclusion: Bcc recipients are not P1 recipients.   P1 recipients are not Bcc recipients, or even a superset of Bcc recipients.   P1 recipients are where an email is going, seen from a specific point, for a specific instance of the email.

So, why are P1 recipients called P1 recipients? It comes from the terminology of the X.400 email standards, and “osmosed” its way into Internet emails lingo (via Microsoft Exchange, which was based on X.400/X.500 at one point). P1 was the protocol for inter-Mail Transfer Agents communications. P2 was the ‘protocol’ for message contents. For instance, the body of an email is P2 data. To and Cc recipients will be listed in the message (somebody receiving the email will see them listed), so are P2 data too (and they also feed the original list of P1 recipients). The Bcc recipients are not P2 data, they only feed the original list of P1 recipients.
When applied to SMTP, the P2 data/content is what’s given to the DATA command, i.e. it’s the actual Internet message to pass along. Headers in that Internet message are therefore sometimes called “P2 headers”. The P1 data/content is the ‘envelope’ information, e.g. the MAIL FROM command (the sender’s address), the RCPT TO command (a recipient’s address); all the information required by SMTP for the email’s transmission. These commands and their content are sometimes called “P1 headers”.