TL;DR: What you’ve presented is not the actual source of the message, but the contents of one of the message’s headers. It is quite likely to be forged. It is quite likely that that address either does not exist or belongs to an innocent third party.
And now, in case you’re curious, here’s a breakdown of the headers belonging to a piece of spam I received in my Yahoo mailbox (and was successfully filtered to the spam folder). This may help you a bit in understanding what you can and can not determine from received e-mail:
First off, here’s what I see in Thunderbird (what I use when I choose to run a mail app):
Note that although the sender claims to be T-Mobile, it has a very different address on its From:
line. But both can be (and as you will see, were) forged. You shouldn’t assume that this address is for the sender. You shouldn’t even assume that that address even exists.
In order to get any potentially useful information, you need to read the raw message headers and understand what you’re seeing. For example, the above message’s headers are:
Received: from 127.0.0.1
by atlas-production.v2-mail-prod1-gq1.omega.yahoo.com pod-id atlas--production-gq1-69c878588f-scsxd.gq1.yahoo.com with HTTP; Tue, 10 Jan 2023 15:52:59 +0000
Return-Path: <>
X-Originating-Ip: [51.77.215.147]
Received-SPF: none (domain of bigopeninfoinc.com does not designate permitted sender hosts)
Authentication-Results: atlas-production.v2-mail-prod1-gq1.omega.yahoo.com;
dkim=unknown;
spf=none smtp.mailfrom=bigopeninfoinc.com;
dmarc=unknown header.from=157041.13.ygxqS6Q.bigopeninfoinc.com;
X-Apparently-To: ...@yahoo.com; Tue, 10 Jan 2023 15:53:00 +0000
X-YMailAVSC: ... (lots of text-encoded binary data) ...
X-YMailISG: ... (lots of text-encoded binary data) ...
Received: from 51.77.215.147 (EHLO bigopeninfoinc.com)
by 10.253.230.152 with SMTP;
Tue, 10 Jan 2023 15:52:59 +0000
To: ...@yahoo.com
From: "T-Mobile®" <VpkxplrlTJ0oAL@157041.13.ygxqS6Q.bigopeninfoinc.com>
Subject: Say Welcome to 2023 with FREE iPhone 14 Pro !
Date: Tue, 10 Jan 2023 16:52:48 +0100
List-id:...@yahoo.com
Reply-to: <odWg7pWg@Atb9iZ.bigopeninfoinc.com>
X-Unsubscribe: <epujGHB0E@W8LH1BdKekTpAR.bigopeninfoinc.com>
Content-type:text/html
Content-Disposition: inline
X-CSA-Complaints: whitelistcomplaints@+eco.de
Message-ID: <LYRIS-Z13Z-X157041X@bigopeninfoinc.com>
Content-Length: 1959
When reading e-mail headers, you should note that it list of tag-value pairs. Each header line begins with the header name (e.g. Received
) then a colon (:
) then (usually) a space, then the text containing the data. Header lines may be wrapped onto multiple lines; if so, each continuing line will begin with whitespace. The block of headers ends with a blank line.
And now a breakdown of the lines in the above header:
-
The first Received:
line was inserted by the last e-mail server to receive the message. This will be a Yahoo mail server, since it was delivered to a Yahoo mailbox.
It is showing that it received the message from itself (the 127.0.0.1
address) via an HTTP-based protocol. This was probably a hand-off from some internal server to their web-mail server, since all of my Yahoo mail begins with a header line like this one.
Every mail server that processes a mail message is supposed to prepend a Received:
header identifying itself. I am pretty sure that mail servers are supposed to prepend Received:
after anything else they choose to prepend.
Which means the subsequent headers should have been added by the server represented by the next Received:
header. any headers beyond the last Received:
header came from the original sender.
Of course, the sender could have included forged Received:
headers, but it is generally going to be obvious because these headers tend to show a path as mail is relayed from server-to-server during the delivery process. And these days, most mail has a very small number of hops (sender’s server to receiver’s server, and maybe a few internal servers at each end). If you see something that doesn’t fit in the chain, it is probably fake.
-
The Return-Path:
is supposed to be an address where message-bounces can be sent so the sender can clean up his contacts/mailing list. The fact that we’re seeing it here (with no data) means Yahoo inserted it. Probably because the actual sender didn’t provide one.
-
The X-Originating-Ip:
header was inserted by Yahoo’s server. From the name, I believe it is the IP address of the server where the mail originated, to the best of Yahoo’s ability to determine. And in this case, it is probably correct (see below)
-
The Received-SPF:
header is part of the Sender Policy Framework protocol for spam detection and was inserted by Yahoo. In this case, it is reporting that the sender’s domain doesn’t maintain a list of hosts permitted to send mail, so it can’t make a determination. See also SPF: SPF Received Header
-
The Authentication-Results:
header contains the results of the server’s anti-spam analysis:
- The name of the server that performed the analysis (atlas-production.v2-mail…yahoo.com)
- The DKIM analysis yields “unknown”. Which is to be expected for a forged sender
- The SPF results (none, as above)
- The DMARC analysis. In this case, indicating that the domain in the
From:
header (157041…bigopeninfoinc.com) is unknown. Which is not in the least bit surprising because the domain doesn’t exist.
-
The X-Apparently-To:
header was also inserted by Yahoo. It contains the recipient e-mail address provided via the SMTP protocol. This address may be completely different from the To:
header, even for legitimate mail (e.g. mailing lists or addresses on a Bcc:
line)
-
The X-YMailAVSC:
header was inserted by Yahoo. It is part of Yahoo’s anti-virus scanning system. I have no idea what the very large block of associated data means.
-
The X-YMailISG:
header was inserted by Yahoo. ISG stands for “Inbound Spam Guard”. For mail you send, there will be an X-YMailOSG:
header, referring to their “Outbound Spam Guard”. Like the AVSC header, I don’t know what the binary data means.
-
Now we come to the next Received:
header. It is a private IP address (10.253.230.152), so this could be anything. But since it inserted all those Yahoo headers, it is reasonable to assume that this is a server in Yahoo’s internal network. it received the mail from IP address 51.77.215.147, which is a cloud-hosting service in France. The sender’s server identifies itself as bigopeninfoinc.com
. But that is bogus, because a quick IP domain search shows that it is not in use by anyone.
The fact that this mail was apparently sent directly from some cloud service (probably a spam-generation server) to the recipient’s mail server is a telltale sign of spam.
Legitimate mail typically originates from the sender’s own mail server (whether hosted by the sender or his ISP), which will insert its own Received:
header(s), with the last one describing the actual source (web server, user’s IP address, list server, etc.) But those headers don’t exist, making it very unlikely that the message came from a legitimate source.
Following the last Received:
header will be all the headers generated by the sender. Any and all of them could be forged and should not be trusted as meaning anything:
-
To:
is supposed to identify the recipient. But it may not be correct even for legitimate mail (e.g. mailing lists or where you’ve been CC’ed or BCC’ed)
-
From:
is supposed to identify the sender. But for this message, it is completely bogus, as we have now determined. The domain name provided doesn’t exist. It fails all the DMARC, DKIM and SPF checks. And there is absolutely no relationship between it and the provided name (“T-Mobile”)
-
Subject:
is the subject you see
-
Date:
is supposed to be the date it was sent, but it can be bogus, even for legitimate mail (e.g. if the sending computer’s clock is wrong)
-
List-id:
This header (or something like it) is typically used to identify a mailing list, so you know who to contact if necessary (e.g. to unsubscribe or request assistance). Placing my e-mail address there makes no sense. But we’re talking about spammers.
-
Reply-To:
is the address replies should be sent to. It’s another completely bogus address, belonging to the same bogus domain. But different from the one on the From: header.
-
X-Unsubscribe:
is supposed to be an e-mail address you can write to in order to be removed from a mailing list. Note that it’s another random address in the same bogus domain.
-
Content-type:
identifies the format of the message body. In this case, HTML
-
Content-Disposition:
makes no sense in the message’s main header. It is meant for attachments to specify if they should be displayed inline with the message content, displayed with an external app, or downloaded when accessed.
-
X-CSA-Complaints:
is part of the Certified Senders program. It is the e-mail address to complain to if the CSA algorithm doesn’t work correctly. It’s very ironic to see a spammer include this and was probably inserted as a half-baked attempt to circumvent spam filters.
-
Message-ID:
is supposed to be generated by the message’s source, in order to provide some form of traceability. Its content should be copied to reply messages via an In-Reply-To:
header, which can help mail apps to organize replies into threads. The actual value is pretty much meaningless.
-
Content-Length:
is the length of the data. It is meant for use in HTTP (web) data transfer. It’s of questionable use in e-mail.