Email sent to me is addressed to [email protected]. How is this done?
An Internet e-mail message consists of two parts. We can refer to them as the envelope and the payload message or simply message.
The envelope has routing data: primarily, this is the sender address and one or more recipient addresses.
The message has the message content: subject line, message body, attachments, and so on. It also carries some technical information such as trace (Received:) headers, DKIM data, and so on; as well as the displayed sender and recipient addresses (what you see in the From, To and Cc fields in your mail client).
Here's the crux of it: The two don't have to agree!
A mail server will look at the envelope data to determine how to send the message. On the other hand, with few exceptions, the message itself will be treated as just data. Particularly, a well-behaved mail server does not look at the To: and Cc: fields of the message itself to determine the list of recipients, nor does it look at the From: field to determine the sender's address.
When you compose and send an e-mail, your e-mail client takes what you entered into the To, Cc and Bcc fields, and translates that into envelope routing information. This is mainly done by removing any full names (leaving only e-mail addresses), but can also involve things like address rewriting, alias expansion, and so on. The result is a list of e-mail addresses which are given to the mail server your mail client is talking to as the list of recipients. The To and Cc lists are kept in the e-mail, but the Bcc is not passed along to the server, making it invisible to message recipients. The sender address works very similarly.
When the message reaches its final destination, the envelope data is either thrown away, or retained in the detailed message headers. That's one part of the reason why Spittin' IT asked for the full message headers in a comment to your question.
Additionally, with Internet e-mail, it is possible to talk directly to a mail server, and thus inject a message that has a mismatch between the envelope data and the message data that a normal, well-behaved e-mail client wouldn't let you compose. Also, mail servers do varying degrees of checks on the sender address that they are given in the envelope data; some barely check it at all beyond making sure it's a syntactically valid e-mail address. The From header of the message data is subjected to even less scrutiny.
Since the receiving e-mail client displays what's in the From, To and Cc headers, not the address data from the envelope, it's possible to put anything you want there and the receiving e-mail client will have no recourse but to trust that it is reasonably accurate. For legitimate mail it usually is accurate enough; for spam, it almost never is.
In the world of tangible, physical objects inhabited by us mere humans, the envelope sender and envelope recipient corresponds to the return address and recipient address, respectively, that you write on the outside of the envelope; and the From: and To:/Cc: headers correspond to whatever you put as your and the recipient's addresses, respectively, in the letter which you put in the envelope.
tl;dr at bottom.
The SMTP protocol doesn't have the notion of CC or BCC recipients; this is a convention held by mail clients. The SMTP server only typically cares about routing information and data. This is an important distinction, because without this capability, BCC could not exist. As a legitimate BCC communication consider the following client transcript:
HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
BCC: "Anonymous" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Now, in this case, Anonymous was sent a message about this meeting. However, this version of the mail was not routed to Jane Doe; she knows nothing about Anonymous being notified. In contrast, Jane Doe will be sent the message with a different body and header:
HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Here, since Anonymous was in the BCC, the message sent to Jane Doe did not include the BCC recipient list. Because of the BCC convention, the email envelope may not include recipients that actually received the message, and it may also include recipients that do not appear in the message headers.
As mentioned by @JonasWielicki, which I also meant to include, is that the MUA (Mail User Agent) is typically responsible for sending the multiple emails that are required to implement BCC. Email servers do not know anything about BCC, and so the MUA must implement BCC by sending multiple emails with different email routes specified in the envelope headers. For this reason, BCCs typically take longer to send than normal emails, because different message bodies must be constructed and sent out individually.
This also helps with some email compliance rules. For example, a mail server may have rules configured to automatically BCC an archive email server (all emails sent to it are also archived), in which case the mail server might not even be a real recipient.
HELO from-mail-server.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA
From: "John Smith" <[email protected]>
To: "Jane Doe" <[email protected]>
BCC: "Anonymous" <[email protected]>
Subject: Important Meeting Notice
Date: Monday, May 15, 2017 12:20 PM
This is an important meeting notice. We'll meet tomorrow.
.
Here, the recipient is another party that is completely undisclosed to any of the recipients or even the sender. This is a feature of the protocol, typically used in relaying or archiving messages.
What this spam message did is take advantage of that behavior. It's a standard loophole that technically should work with any compliant mail server. Of course, many updated servers use "extensions" like DKIM to verify that such an email is authentic, but there are still many old mail servers out there that don't care, simply because it's tempting to not fix things that are not broken.
Also note how I've specified a Date header. This can be any arbitrary (but well-formatted) value; many clients will happily display any legal date range from the distant past to the far future. I have personally sent an email to myself years ago that will remain at the top of my mail box long after my life expectancy, as well as an email that predates my email account and my own birth.
tl;dr
So, in summary, the sender spoofed an email, the originating mail server accepted/relayed it, your email server accepted it and stored it in your inbox, and your client faithfully displayed the data that was in your inbox to you, all without circumventing any security. "Sending" security is often much less restricted than "receiving" security in that perspective, since POP3 almost always requires a username and password before you can access a mail box (you could theoretically circumvent this, but I don't know of any legitimate mail services that do).
SMTP and email are very old Internet services from an era when security and authentication were taken much less seriously (DNS is another example). The design of the protocol makes no effort to verify the authenticity of the sender address, and only validates the recipient address insofar as it is ensuring that the mail is deliverable.
Email is transmitted through the SMTP protocol. The SMTP protocol is relatively dumb; it provides a facility to transmit plaintext to an email address and very little more. The structure of this plaintext is defined by RFC 5322. The general idea is that the email text has metadata called a header, and the actual text body of the message. This email header is generated by the sender (none of it can be trusted) and contains fields like "to:", "from:", "subject:", etc...
The SMTP protocol does not (and is not supposed to) validate that the email headers match any of very few things defined in the SMTP protocol, which are essentially your email address and a sender email address that is never validated in any way.
Almost everything in an email message can be fake.
The only thing even remotely trustworthy about email contents today are DKIM signatures, which prove that the email was processed through an email server sanctioned by the domain registrant. Digging deeper, you would find that this scam email has no DKIM signature.