I got an empty email in my language (Hebrew) with only a title that can be translated to I am still waiting for your feedback (original: עדיין מחכה למשוב שלך)

Since my gmail handle multiple accounts (by forward and by user\pass) I tried to figure out which account was the target, and to my surprise - None!

Strange email without To

My question is simple, why gmail chose to put this email in my inbox? Attached bellow is the full source of the email (from gmail) except my censored email. How is this not a security breach\stopped by spam filters?

Original Message:

  • Message ID <1516107259.760993983@f493.i.mail.ru>
  • Created at: Tue, Jan 16, 2018 at 2:54 PM (Delivered after 2 seconds)
  • From: joseph andrew Using Mail.Ru Mailer 1.0
  • To:
  • Subject: עדיין מחכה למשוב שלך
  • SPF: PASS with IP Learn more
  • DKIM: 'PASS' with domain bk.ru Learn more
  • DMARC: 'PASS' Learn more
Delivered-To: ****<cencored>****@gmail.com
Received: by with SMTP id q86csp4037724jad;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
X-Google-Smtp-Source: ACJfBotHqXkzj6W7gd+8IjEmxrwG9SqXBSC+QiTqyAB1j2Dt4ASXtmXr5UpqIpdU7Mge/EFmnzVI
X-Received: by with SMTP id e76mr192303ljf.115.1516107261904;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1516107261; cv=none;
        d=google.com; s=arc-20160816;
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass header.i=@bk.ru header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of joseph.andrew@bk.ru designates as permitted sender)
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
Return-Path: <joseph.andrew@bk.ru>
Received: from f493.i.mail.ru (f493.i.mail.ru. [])
        by mx.google.com with ESMTPS id 1si926950ljd.480.2018.
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
Received-SPF: pass (google.com: domain of joseph.andrew@bk.ru designates as permitted sender) client-ip=;
Authentication-Results: mx.google.com;
       dkim=pass header.i=@bk.ru header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of joseph.andrew@bk.ru designates as permitted sender)
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:From;bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; b=kgyoMcicHiqU/OvYmq/2sQYQ3607jIk9ZHkh3oVDZTrA6cWDxLGvol37xuQ3L0mfrqIOpSTYHuJzssIjww+4FL/h/GwBRRO1AsuLgxyjSQaOLVqidNe0MUIz6EVQxYXLcUCl9USryPLWAWKBiwL80efALu5znH8K96P6fF33Gzw=;
Received: by f493.i.mail.ru with local (envelope-from <joseph.andrew@bk.ru>) id 1ebQkt-0004Zj-4G; Tue, 16 Jan 2018 15:54:19 +0300
Received: by e.mail.ru with HTTP; Tue, 16 Jan 2018 15:54:19 +0300
From: joseph
  andrew <joseph.andrew@bk.ru>
Subject: עדיין מחכה למשוב שלך
MIME-Version: 1.0
X-Mailer: Mail.Ru Mailer 1.0
Date: Tue, 16 Jan 2018 15:54:19 +0300
Reply-To: joseph
  andrew <joseph.andrew@bk.ru>
X-Priority: 3 (Normal)
Message-ID: <1516107259.760993983@f493.i.mail.ru>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Authentication-Results: f493.i.mail.ru; auth=pass smtp.auth=joseph.andrew@bk.ru smtp.mailfrom=joseph.andrew@bk.ru
X-7FA49CB5: 0D63561A33F958A5898151702DBFE222A841889EBAE90B8E20672C31CB87FE38725E5C173C3A84C39B8A9203B4187291E49527301AB7C5D479C543ECCDAE434EC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F20A889B128FC2D163B503F486389A921A5CC5B56E945C8DA
X-Mailru-Sender: AEEF7784B292FD580FA14CB39DA65BAAC14FF9386EF48BFAB56EC34AB37A73FC68AD8B15A0E9EE36875DC23763F10D8F75E89B9EB25B1370F805D6321A69DA8E2FB9333096616C166E245241366DF001CF5B8F1B83B229A3C432A6261406F5E9E7E03437FF0094633453F38A29522196
X-Mras: OK
X-Spam: undefined


Tried to send with bcc and empty "to" and gmail showed the bcc. So currently @Luc answer seems to be the real answer (RCPT TO was used).

BCC try fail

  • 5
    Similar question on Superuser: Why is my own e-mail address not listed in the To field? Jan 16, 2018 at 14:24
  • 6
    I've configured spam filters to reject blank To: fields before, so it is possible for spam filters to stop this. The downside is that some legitimate (and IMHO foolish) senders want a blank To: field so they can e-mail a large group of people without exposing all of their addresses to each other. Sometimes I've gotten away with saying they have to put something (like their own address) in the To: field, other places I've been ordered to allow empty "To:" fields through the spam filter. Jan 16, 2018 at 18:17
  • 3
    "I tried to figure out which account was the target" -- The "To" MIME header is useless for that anyway since it is under the control of the untrusted sender, look instead at the Delivered-To header which was attached by your own server.
    – Ben Voigt
    Jan 17, 2018 at 0:07
  • 2
    Your BCC test is not a good test. You are using GMail, which (a) knows you are the sender (b) may do odd things anyway. To test, you need to send from a different address at the very least -- one which is not yours -- and preferably not use GMail as a client at all. Jan 17, 2018 at 1:06
  • 4
    Just a note: Your attempt to cover the name an email in the "Edit:" image is really not sufficient. Not only is the full lettering not covered, but the covered portions are different in every instance, making a large portion of the text retrievable.
    – Zach
    Jan 17, 2018 at 16:54

4 Answers 4



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:<user1@example.com>
RCPT TO:<user2@example.com>
RCPT TO:<user3@example.com>
RCPT TO:<user4@example.com>
Subject: test
From: <user1@example.com>
To: <user2@example.com>
CC: <user3@example.com>

Hi Jake,
Just letting you know that email works.


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 joe@a.example.com and stefan@b.example.com, 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.

  • 4
    Is there a reason why this info isn't usually delivered to the recipient? To me it sounds like it should be an obvious thing to require do when you design an email protocol.
    – JiK
    Jan 16, 2018 at 15:52
  • 42
    @JiK (a) The internet was more innocent back then; (b) the RCPT TO: lines are like the address on an envelope, the To: line is what appears on the letter inside it. It used to be (maybe still is) that in some offices, mail-room staff would open the envelopes (unless makred Private & Confidential) and only give you the contents. SMTP works a bit like that.
    – TripeHound
    Jan 16, 2018 at 16:22
  • 19
    @JIK: It was delivered to the recipient. It's right there in the Delivered-To MIME header on the very top of the source. It's just the dumb email program not displaying it.
    – Ben Voigt
    Jan 17, 2018 at 0:09

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, because false information can be used to deceive recipients.

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.

  • 2
    It's still baffling that after all theses years noone bothered to implement a more secure standard Jan 18, 2018 at 4:58
  • 7
    @HopefullyHelpful it's not baffling. It is extremely difficult to change such an old standard and not outright break almost everything that uses it. SMTP made assumptions about users being scientists. The end users were the security. The internet was not designed at all as a consumer service. Not even close.
    – Nelson
    Jan 18, 2018 at 7:51
  • Perhaps worth mentioning that some MTAs will include a for clause in their Received: headers, showing the envelope RCPT TO on that hop. I haven't checked, but I expect that this is done only when there's a single recipient (for privacy); there don't seem to be any such for clauses in the question's headers. Jan 18, 2018 at 11:32
  • @TobySpeight This is only true if there is only one RCPT-TO. Jan 19, 2018 at 15:37
  • 1
    Probably worth noting that when you say "newer versions of the protocol", that means "newer than 1995".
    – mattdm
    Jan 19, 2018 at 15:52

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

  • 10
    that's the most simple/logical explanation. Jan 16, 2018 at 14:04
  • 3
    I tried and failed to reproduce. Luc answer above seem to be the right one (see my edit)
    – YoniXw
    Jan 16, 2018 at 17:55

It can be surprising, but this is quite normal in the SMTP protocol. A message is composed of headers and a body. It is send over a chain of Mail Transport Agents. No agent should change the body, but they can change the headers, mainly to add a Received field, a Date field if it is not present and any other field as required by their own processing. But neither the To nor the From field are special, and in particular they are not used to deliver the mail. The MTAs use what is called the envelope, that is what is passed in the MAIL FROM and RCPT TO commands of the SMTP protocol.

Mail User Agents (like Thunderbird) do use the To, Cc and Bcc fields to build the envelope, but if you know the SMTP protocol, it is easy to send a mail with forged or absent To and From headers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.