Skip to main content
Super User

Return to Answer

added 568 characters in body
Source Link
phyrfox
phyrfox
  • 3.1k
  • 21
  • 17

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.

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.

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.

Source Link
phyrfox
phyrfox
  • 3.1k
  • 21
  • 17

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.

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).