How did I get this email without a "To" field?

Why?

Two explanations:

• BCC
• Spam

I've often gotten spam where they seem to want to hide to whom it was addressed for some reason. Since I have a catch-all on my domain, it will arrive for me no matter what address they used (unless they used one which I blacklisted).

How is this possible?

SMTP traffic looks like this:

EHLO example.com 
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
RCPT TO:<[email protected]>
DATA
Subject: test
From: <[email protected]>
To: <[email protected]>
CC: <[email protected]>

Hi Jake,
Just letting you know that email works.

.
QUIT

You can open a TCP connection to any mail server and type this, and it'll respond to you and deliver your email (I've omitted responses in the example). On Windows, install Telnet from the Windows features menu and type telnet example.com 25 to connect to the server at example.com on port 25.

As you can see, user4 was addressed in the RCPT TO and it will end up in their email inbox, but they are not mentioned in the from, to or cc headers of the email data. The email data, from the DATA command until the . on a line by itself, is the part that you will see when you open "view source" in your email client. So it has little to do with the actual email exchange. Of course it usually matches, but in a malicious case, they don't care what is "usual". And in the case of BCC you'll also not see it.

I've often gotten spam where they hide where it was sent to. In order to be able to trace it, I have to dig in my mail server logs.

A server administrator can also lookup BCCs like this, though of course only of their own domain (if it was BCC'd to [email protected] and [email protected], the administrator of a.example.com will not see stefan).

As to why you can send GMail to yourself in the BCC and see a BCC field with yourself listed on the receiving end: the email program/provider can just send separate SMTP messages for each recipient in the BCC, with the BCC header crafted in the nested email header to list only that recipient.

Headers like To, Cc and Bcc are essentially all cosmetic; they don't control the actual receipient of an email according to the SMTP protocol. It's possible to put whatever you like into these fields and still have separate control over who the email goes to at the protocol level.

When you send an email on the internet your sending mail server communicates with the receiving mail server by SMTP. To send an email, the sending server sends a series of commands to the receiving server.

1. A HELO command specifying the sending server's hostname (This can be replaced by EHLO (short for "Extended HELO") in newer versions of the protocol).
2. A MAIL FROM command announcing the address of the sender of the email.
3. A RCPT TO command announcing the addresses of the message recipients.
4. A DATA command announcing the start of the message itself, including headers and body.

Headers in the message such as To, Cc or Bcc are not acted upon or used, but are transmitted without modification.

If these headers are ignored by the sending and receiving mail servers, why do they exist?

Because they are a common convention used by mail user agent (mail client) software, which is the software that the user actually interacts with to send mail. The usual way for a mail client to work is that the user types recepient addresses into three fields within the mail client called "To", "Cc" and "Bcc" which the mail client uses as a basis for who to send the message to. The mail client then takes what was written in the "To" and "Cc" fields and places them into mail headers called "To" and "Cc" as an indicator to the recipient of what the sender originally typed in these fields. This is merely a courtesy to the receiving mail client; the sending mail client could choose to keep this secret - indeed, that's what happens with its "Bcc" field: the mail client never creates a "Bcc" header in the email it sends, because the point of that feature is that it's not included in the mail itself.

The mail client also contains a "Subject" field which it places into the mail as a "Subject" header, and it creates a "From" header in the email with information about the sender.

How is this not a security problem?

It is. It makes it trivially easy to put fake information about the sender or recipients into an email. When users trust that this is accurate and it isn't, that's a potential security problem.

Mail clients could simply ignore such headers, but then you would miss out on the convenience of knowing who an email was addressed to when this information exists and is genuine, and by the same logic you'd also have to ignore the "From" and envelope sender (MAIL FROM command) as well, leaving no indication of who sent it. So mail clients take the approach that there is more benefit in showing this information even if it can be faked.

A new standard called DMARC, piggy-backing on other standards DKIM and SPF, can allow a receiving mail client to verify the domain/hostname part of the "From" header is genuine. While this only verifies part of the "From" header and does not verify the "To" or "Cc" header, it allows you to know that the mail was genuinely from the system it claims to come from. If this is a trusted system, you can at least infer that the mail and its headers were created by an authorised user of that system.

Besides these options, email simply wasn't designed for all this to be verifiable. If you want more, you have to use some form of cryptographic verification such as PGP on top of your message and have some out-of-band way of verifying authority.

So far I think that your address was used as BCC.