63

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 <[email protected]>
  • 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 217.69.138.160 Learn more
  • DKIM: 'PASS' with domain bk.ru Learn more
  • DMARC: 'PASS' Learn more
Delivered-To: ****<cencored>****@gmail.com
Received: by 10.2.76.217 with SMTP id q86csp4037724jad;
        Tue, 16 Jan 2018 04:54:21 -0800 (PST)
X-Google-Smtp-Source: ACJfBotHqXkzj6W7gd+8IjEmxrwG9SqXBSC+QiTqyAB1j2Dt4ASXtmXr5UpqIpdU7Mge/EFmnzVI
X-Received: by 10.46.101.207 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;
        b=O+SDwmDS2Y7Jxi+mhwkV/+svfXK0KI3VvepeQgBpyhlgYY5gK3wln+RC4YPO+MMn71
         tyrGBUoc1iGKpeGcilWAovf0XLceJY+EAGoMX4Hl4Pse8C5mWiP0DJQXfmolB5myOFD/
         EoSl7Km4KDcQsvSC0DGwcni1yUPjgiQr+KIY+y19WCqVfm5EtCkbYkUCnFP1RWh/BUBp
         YZHKJrRYH/gWsSqBuIm/fDuSFk4bYAFaCOfkq5LfJcnkf7lpRFBnNYseignqwnnYMEzB
         aScqj1ppvCoYLbBuEiw+yLo1iQLoNdXwGOLShsGXELxkpdFpmchOEV44Wx2vp+RlJMF0
         v1/A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=content-transfer-encoding:message-id:reply-to:date:mime-version
         :subject:from:dkim-signature:arc-authentication-results;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=IPjf/U3N1a7Dx8HIw59iWKeccU4mS7Bd0Iy2FY/Be4Mx4QATd8uBvH7pLOVOLHRAXj
         iATzKUy69ZyLgu6gJVc+yjW3+i740O9ccPNbWAPQQASX1H9OkiMsmlhNYOU5u4KDKfbj
         nNm77TeMxrF57z4XKpbO3iE4YEv6JFankI949HvLnehC7wPP5M5YHpS8CllmV3zP8RX4
         2kb14n4PzguduwYoHL3q7wwWHHnyPUsa3UuhCKLvNJYw4KWKLWNY6Kt7fwReb83T+OsG
         lavZ7huDrCcf0P8Ee7YGepcNpGFyh2WjpA4o7l+gAlnqsb6+5FZloH6j7cmQx/gA+gKh
         aVng==
ARC-Authentication-Results: i=1; mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bk.ru
Return-Path: <[email protected]>
Received: from f493.i.mail.ru (f493.i.mail.ru. [217.69.138.160])
        by mx.google.com with ESMTPS id 1si926950ljd.480.2018.01.16.04.54.21
        (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 [email protected] designates 217.69.138.160 as permitted sender) client-ip=217.69.138.160;
Authentication-Results: mx.google.com;
       dkim=pass [email protected] header.s=mail header.b=kgyoMcic;
       spf=pass (google.com: domain of [email protected] designates 217.69.138.160 as permitted sender)
       [email protected];
       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 <[email protected]>) 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 <[email protected]>
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 <[email protected]>
X-Priority: 3 (Normal)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64
Authentication-Results: f493.i.mail.ru; auth=pass [email protected] [email protected]
X-7FA49CB5: 0D63561A33F958A5898151702DBFE222A841889EBAE90B8E20672C31CB87FE38725E5C173C3A84C39B8A9203B4187291E49527301AB7C5D479C543ECCDAE434EC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F20A889B128FC2D163B503F486389A921A5CC5B56E945C8DA
X-Mailru-Sender: AEEF7784B292FD580FA14CB39DA65BAAC14FF9386EF48BFAB56EC34AB37A73FC68AD8B15A0E9EE36875DC23763F10D8F75E89B9EB25B1370F805D6321A69DA8E2FB9333096616C166E245241366DF001CF5B8F1B83B229A3C432A6261406F5E9E7E03437FF0094633453F38A29522196
X-Mras: OK
X-Spam: undefined

Edit:

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

Improve this question
11
  • 5
    Similar question on Superuser: Why is my own e-mail address not listed in the To field?
    – Nisarg Shah
    Commented 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.
    – Todd Wilcox
    Commented 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
    Commented Jan 17, 2018 at 0:07
  • 3
    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.
    – Andrew Leach
    Commented 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
    Commented Jan 17, 2018 at 16:54

5 Answers 5

Reset to default
89

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.

Improve this answer
3
  • 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
    Commented Jan 16, 2018 at 15:52
  • 43
    @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
    Commented 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
    Commented Jan 17, 2018 at 0:09
39

Headers like To, Cc and From are essentially all cosmetic; they don't control the actual receipients or senders 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 (EHLO - "Extended HELO" - can be used if you want to be able to use features from ESMTP).
  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 From are not acted upon or used by the sending or receiving mail servers (MTAs), but are transmitted without modification.

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

They were designed to be a user focused representation of who the email was from and to. These fields are a feature used by mail client software (MUAs), which is the software the user actually interacts with to send and read 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 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 convention; 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.

In addition to this the mail client also contains a "Subject" field which is also placed into the email headers. And it adds a "From" field based on information added by the user about who they are.

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.

Email was designed in an age where bad players (scammers, spammers, malware) were not adequately predicted, so it wasn't properly predicted that these could be used to deceive or impersonate. But, fixing this issue now while retaining the decentralized nature of email is difficult.

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.

Improve this answer
5
  • 2
    It's still baffling that after all theses years noone bothered to implement a more secure standard
    – HopefullyHelpful
    Commented Jan 18, 2018 at 4:58
  • 8
    @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
    Commented Jan 18, 2018 at 7:51
  • 1
    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.
    – Toby Speight
    Commented Jan 18, 2018 at 11:32
  • @TobySpeight This is only true if there is only one RCPT-TO.
    – Johannes Kuhn
    Commented Jan 19, 2018 at 15:37
  • 2
    Probably worth noting that when you say "newer versions of the protocol", that means "newer than 1995".
    – mattdm
    Commented Jan 19, 2018 at 15:52
18

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

Improve this answer
2
  • 10
    that's the most simple/logical explanation.
    – baldPrussian
    Commented 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
    Commented Jan 16, 2018 at 17:55
15

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.

Improve this answer
1

Expanding on the very good answer from @Luc...

The To: header is missing because the sender excluded it in the DATA portion of their SMTP message for some reason. They used RCPT TO to tell your mailserver where the message (DATA) should be delivered so it still arrives in your inbox.

When I see cases like this (missing To: header), if I look at the full headers on the received email in my email client, I can see what address was used for RCPT TO in a Received: header.

Not sure if gmail exposes this or not. I run a fairly vanilla postfix/dovecot mailserver.

If you have many addresses or aliases or a catch-all that ends up in the same email inbox and you want to know which address the message was actually sent to (e.g. which of your addresses the sender has in case you want to block it), then you can get this from the email headers in your email client (at least in my case) and you don't need to get into mailserver logs.

Example:

Received: from sending-server.example.com (sending-server.example.com [X.X.X.X])
    (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
    (No client certificate requested)
    by my-server.example.com (Postfix) with ESMTPS id XXXXXXXXX
    for <[email protected]>; Sun,  8 Jan 2023 10:43:20 +0000 (UTC)

Obviously I changed IPs and domains to be examples, but otherwise the above case is a real header from an email I received today where there was no To: header. You can see the email was RCPT TO [email protected] and that is why I received it.

In Postfix you can use config enable_original_recipient to get Postfix to add a X-Original-To header.

Some PostFix configs that might help...

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .