Agreed. Although that behavior may be changing as security threats are being taken much more seriously.
The sender of a mail message can send it with any header, and the mail-transfer protocols are not supposed to alter or remove any headers.
But: The various servers that a message passes through on its way from source to destination all append their own headers. At minimum, each will append a Received: header line which (at minimum) identifies the server and the IP address it received the message from. Many will append additional information.
It’s not too difficult to review these headers. Although a sender may forge some Received: headers, the real servers will all append their own. So you can (without too much effort) trace the path to the server where it actually originated. And you can look at any headers appended after that point to see what else the intermediate servers provided.
You can’t always identify the actual sender, but you can almost always identify the server where the sender injected the message, which is often sufficient to prove whether sender-identifying headers are accurate or are forged.
David,
Basically what I said in not so much detail. My response was mostly to Schwartz that said because ‘from’ header could be spoofed, no use referring spam e-mails from known big name companies to the company IT department as users abusing, or hackers using, their systems. From the headers you find out if the spam really was from ibm.com or not. The reason for my original post and Schwartz stated I was wasting IT people time
Do you know how to forward an email to a “big name company” that would include all the intervening headers? If not, it is useless to them. If you do, it is also of little value for them to investigate an outside originating server that injected a spoofed email.
The only way your actions might be of value is if you first carefully examined all the headers and determined that the originator was indeed under their control. Since these could also be covertly inserted in the originating fake email, I still maintain that it wastes their time to do more than to ignore the “report”, or to do even a casual glance at the entire set of headers, if they were included at all.
1 Like
It has been ages since I’ve last looked into our DMARC settings, but I could make that change. It was never quite clear to me what real-world effect it might have on our deliverability.
1 Like
I’ve never got my head around it either, but when I turned on DMARC reporting the result was a load of emails I couldn’t understand and so regularly deleted. I turned it off, as far as I can tell it doesn’t make any difference to deliverability. So until I hire a security team 
I’m going to keep it off.
Dana,
If the e-mail truly came through their SMTP server, easy to spot/determine in headers, either an employee is misusing, or they have been hacked. Period!
Paul
Alright, no more back and forth about the value of reporting to IT managers—the conversation has devolved into personal sniping. Any further posts along those lines will be deleted.
I’m leaving the topic open in general for technical posts surrounding SPF, DKIM, and DMARC for those of us who do use them. (And as @chuckhoupt notes, TidBITS has supported all three for many years, though I wasn’t comfortable switching out of “monitor only” mode. The DMARC FAQ says:
A domain owner who has deployed email authentication can begin using DMARC in “monitor mode” to collect data from participating receivers. As the data shows that their legitimate traffic is passing authentication checks, they can change their policy to request that failing messages be quarantined. As they grow confident that no legitimate messages are being incorrectly quarantined, they can move to a “reject” policy.
But I have absolutely no data showing anything about what DMARC is doing or not, so how would I know if I could switch to quarantine or reject?
If you’re getting DMARC reports, then you should have a pretty good idea of the deliverability impact. But “preventing spoofing” and “delivering my email” can be competing goals. I guess it’s a trade off between the reputational impact of spam appearing to originate from TidBITS vs. complaints from readers that they aren’t getting your email (because of a hyperactive or mis-configured intervening mail server). Personally, I want to be notified about a spoof attempt, but I want to decide if it truly is one. So I keep my DMARC setting on “monitor”.
Sorry, I pushed my Reply button just after you posted. 
Receiving DMARC reports requires the rua and ruf tags in your DMARC record. Here’s the DMARC report reader I use: dmarcian - DMARC XML to Human Converter
Thanks—I’m dimly remembering that I used to get those reports but they were completely inscrutable so I eventually turned them off. I’ll have to dive back in sometime, though it’s a low priority.
1 Like
I am not sure how new this is to Mail (Version 16.0 (3696.120.41.1.1)). But I got a spam e-mail with a spoofed ‘from’ username. But clicking on the from ‘user name’ shows the real sender that shows up in the headers.
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.1address) 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 prependReceived: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 lastReceived: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 theTo:header, even for legitimate mail (e.g. mailing lists or addresses on aBcc: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 anX-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 asbigopeninfoinc.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 anIn-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.
5 Likes
David,
Interesting. But if all that can be bogus, why does Google and many others want the raw headers when reporting spam?
Paul
The “From:” header can all be bogus, so they need some of the other headers in order to trace back to the actual sender.
Not all of it is bogus. As I wrote, each mail server prepends headers to the message, and the last one prepended is always a Received: header.
Header lines following the last Received: header come from the sender and may be bogus. Header lines above that come from the various mail servers the message passed through.
Although those headers may not be able to identify the sender, they can often be used to determine the first server the message passed through and the IP address of whatever computer sent it there.
This, in conjunction with other similar reports, is usually enough to identify the server/network that is sending the spam. This may be run by the spammers, or it may be a system that was hacked by the spammers. Either way, it gives them enough information to take action - either by blocking the server or by contacting its administrators.
3 Likes
So can’t one manually look at the headers and surmise the server/network that is sending the spam? And it is either a spammer run or a system that was hacked by spammers, and gives them enough information to take action. Isn’t this what I started with my original post, and told I was wasting IT manager’s time?
Sure, but SpamCop is faster and more efficient. For instance, they have been informed by several IT managers that they don’t want to receive such reports. They also go through the ISP registration data to figure out the correct address to send spam reports to.
4 Likes
I don’t get it, IT managers don’t want to know they have problems?
There are a few email ISPs that openly host spammers and rely on fees from them to stay in business.