Home / Technology / What do all the elements contained in the e-mail headers mean and how do you detect spoofing?

What do all the elements contained in the e-mail headers mean and how do you detect spoofing?

If you think about it, maybe you should not open it at all.
Enlarge / If you think about it, maybe you should not open it at all. [19659004] Aurich / Thinkstock

I often receive requests for help from someone who has been imitated – or whose child has been imitated – by e-mail. Even when you know how to "display headers" or "view source" in your email client, the diagnostics flow wharrgarbl can be pretty damning if you do not know what you're looking at. Today, we will be browsing a set of real-world (anonymized) email headers and describing the process for determining the type of what.

Before we start with the headers, let's take a quick detour through a preview of what the general path of an email message looks like. (The more experienced types of system administrators who already know what "MTA" and "SPF" represent can jump a little forward to the fun part!)

From MUA to MTA, then back to MUA [19659007] The Basic Components Mail User Agent and Mail Transfer Agent are involved in sending and receiving e-mail. In short, a MUA is the program you use to read and send mail from your own personal computer (Thunderbird, Mail.app or even a webmail interface such as Gmail or Outlook), and MTAs accepting messages. senders and route them to their final recipients.

Traditionally, mail was sent to an e-mail server using the Simple Mail Transfer Protocol (SMTP) and was downloaded from the server with the help of the Post Office. Protocol (abbreviated as POP3 because version 3 is the most used version of the protocol). A traditional email user agent, such as Mozilla Thunderbird, would need to know both protocols; it would send all of its user's messages to the user's mail server via SMTP and download the messages intended for the user from the user's mail server using POP3.

Over time, things got a bit complicated. IMAP largely replaced the POP3 protocol because it allowed the user to leave the actual email on the server. This meant that you could read your mail from multiple machines (perhaps a desktop computer and a laptop) and have all the same messages, organized in the same way, wherever you could check them.

Finally, over time, webmail. has become more and more popular. If you use a website like MUA, you do not need to know the tedious settings of the SMTP or IMAP server; you just need your email address and password, and you're ready to read.

In the end, any message from one human user to another follows the path of MUA MTA (s) MUA. Analyzing e-mail headers involves following this feed and looking for any fun activity.

TLS Encryption in Flight

The original SMTP protocol absolutely did not think about security – no server was supposed to accept any message, regardless of the sender. and send the message to any other server that, in his opinion, might know how to get to the addressee in the To: field. It was good and dandy at the time of the earliest e-mail days of email machines and trusted people, but quickly became a nightmare as the Internet grew exponentially and gained commercial value

. but such messages will most likely be rejected along the way by anti-spam defenses. Modern email is usually encrypted in flight, signed and authenticated at rest. The in-flight encryption is done by TLS, which prevents the contents of a message from being captured or tampered with in flight from one server to another. This is fine, but the TLS in flight is applied only when the mail is relayed from one MTA to another MTA along the delivery path.

If an e-mail goes through the sender via three MTAs before reaching the recipient. any server en route can change the content of the message. TLS encrypts the transmission from one point to another, but does nothing to verify the authenticity of the content itself, nor the path it traverses. 19659007] SPF – Sender Policy Framework

The owner of a domain can define in his DNS a TXT record indicating which servers are allowed to send messages on behalf of that domain. For a very simple example, The recording SPF of Ars Technica indicates that the email from arstechnica.com should only come from the servers specified in ] Google's SPF registration . Any other source should encounter an error SoftFail ; it actually means "do not trust him, but do not you do it necessarily to the sun based solely on that."

The SPF headers in an email can not be completely reliable once generated because there is no encryption implemented. SPF is only really useful for the servers themselves, in real time. If a server knows that it is at the outer limit of a network, it also knows that any message received must come from a server specified in the domain's SPF registration. 39; sender. This makes SPF an excellent tool for getting rid of spam quickly.

DKIM – Mail identified by DomainKeys

In the same way as SPF, DKIM is defined in the TXT records of the DNS of the sending domain. Unlike SPF, DKIM is an authentication technique that validates the message content itself

The sending domain owner generates a public / private key pair and stores the public key in a record TXT on the DNS of the domain. Mail servers at the outer edge of the domain's infrastructure use the DKIM private key to generate a signature (a correctly encrypted hash) of the entire message body, including all heads accumulated at the exit of the infrastructure of the sender. Recipients can decrypt the DKIM signature by using the DKIM public key extracted from the DNS server, and then verify that the hash matches the entire body of the message, including the headers, as they were. received.

If the decrypted DKIM signature is a corresponding hash for the whole body. , the message is likely to be legitimate and unchanged – at least as verified by a private key owned only by the domain owner (the end user does not have or does not need it of this key). If the DKIM signature is not valid, you know that the message does not come from the domain of the alleged sender or has been changed (even if it is only by adding additional headers) by another intermediary server. Or both!

This becomes extremely useful in trying to determine if a set of headers is legitimate or falsified: a corresponding DKIM signature means that the sender's infrastructure guarantees all the headers located below the signature line. (And all that also means – DKIM is only one tool in the mail server administrator's toolkit.)

DMARC: Authentication, Report and conformance of domain-based messages

DMARC extends SPF and DKIM. This is not particularly exciting from the point of view of someone who is looking to find a potentially fraudulent email; it comes down to a simple set of instructions for mail servers regarding the management of SPF and DKIM records. DMARC can be used to request a mail server to transmit, quarantine, or reject a message based on the result of the SPF and DKIM file check, but it does not add any additional control by itself.

Analyzing an Example of an Email

Below is a set of actual headers from a real email. They indicate a relatively complicated – but legitimate – access path from an AOL account to a locally hosted Exchange server. They have been heavily redacted, with IP addresses, host names, and modified timestamps, but they are still sufficiently intact to be scanned.

We will divide it into pieces, but we read them strictly in the order indicated. from top to bottom. Each server along the way adds its own header to the on it of the raw email body, over the headers of all the servers that preceded it. So, when you read them, you leave the final destination MTA and go down to the MTA that first accepted the MUA's message from the sender.

Group 1: Exchange hosted infrastructure locally

  Received: from REDACTED01.exch.domain.local ( from
REDACTED01.exch.domain.local ( with Microsoft SMTP Server
(version = TLS1_2, number = TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id
15.1.1713.5 via the transport of letter boxes; Tue, 06 Aug 2019 09:51:59 -0400

Received: from REDACTED01.exch.domain.local ( by
REDACTED01.exch.domain.local ( with Microsoft SMTP Server
(version = TLS1_2, number = TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id
15.1.1713.5; Tue, 06 Aug 2019 09:51:59 -0400

Received: from redacted2.privatedomain.net ( by
REDACTED01.exch.domain.local ( with Microsoft SMTP Server
(version = TLS1_2, number = TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521) id
15.1.1713.5 via frontal transport; Tue, 06 Aug 2019 09:51:59 -0400 

Looking at the first header blocks of this message, we can see that it has been received by a local Microsoft Exchange server managed by the recipient's organization (that is, Office365 or Azure). We can also see that the message is sent via SMTP encrypted en route on these two hops and what ciphers were used.

We know that it is a Microsoft Exchange server both by the hostname (private) and more directly by the name of the application "Microsoft SMTP Server" indicated in each header block.

Note that each IP address of these blocks is private. Any IP address beginning with 10. is private and can not be publicly routed according to IETF RFC1918 . This indicates that this mail step was done on a private network and not on the Internet. We have not yet left the local infrastructure.

When we get to the third header block, received from redacted2.privatedomain.net we mark the transition from the local Exchange server to mail filtering. a service. We can see that even though we still have not left the private network space, we have moved to a probably different subnetwork, from local 10.11.xx to 10.4.xx . -Who can indicate a VPN tunnel to a different location or just a different VLAN on the same global LAN. As the IP address is private, it is impossible for us to find out more. We can also see that this leg of the trip was not strictly SMTP; it was "via Frontend Transport", a protocol specific to Microsoft Exchange.

Second group: a third party filtering service

  Reived: from redacted3.privatedomain.net (redacted3.privatedomain.net [])
(with TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384 (256/256 bit) encryption)
(No client certificate requested)
by redacted4.privatedomain.net (Postfix) with the ESMTPS ID 9935F120006
for ; Tue, 06 Aug 2019 06:52:59 - 0700 (PDT)

Received: from redacted4.privatedomain.net (redacted4.privatedomain.net
(with TLSv1.2 with ECDHE-RSA-AES256-GCM-SHA384 (256/256 bit) encryption)
(No client certificate requested)
by redacted5.privatedomain.net (Postfix) with the ESMTPS ID 6AB16120005
for ; Tuesday, 06 August 2019 06:52:59 - 0700 (PDT)   

Although we are still on a private network, as seen by IP addresses 10.xxx we can see that we have left the Exchange ecosystem: the next MTA in the chain is running Postfix, a common Unix-based MTA (I'm using "Unix-based" here as a replacement for Linux, BSD, and all the other operating systems * nix-y, I'm also very aware of the differences between a kernel and a distribution, so do not record a semantic argument.We can also guess, following the sudden change in timezone of the server, that we are probably no longer on the local network.The Postfix server of this jump is at Pacific time, while the local Exchange servers were at the time of the East. This is most likely a third-party email filtering service, which can remove the pi attachments of spam and / or malware from incoming emails.

Third group: outlook.com mail service

  Received: from NAM03-CO1-obe.outbound. protection.outlook.com
(mail-co1nam03lp2053.outbound.protection.outlook.com [])
(using TLSv1.2 with ECDHE-RSA-AES256-SHA384 (256/256 bit) encryption)
(No client certificate requested)
by east.smtp.mx.exch.serverdata.net (Postfix) with ESMTPS ID 299186001F
for ; Tue, 06 Aug 2019 06:52:59 - 0700 (PDT)

Received: from CO1NAM03FT022.eop-NAM03.prod.protection.outlook.com
( from CO1NAM03HT180.eop-NAM03.prod.protection.outlook.com
( with Microsoft SMTP Server (version = TLS1_2,
cipher = TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.1987.11; Tue, 06 August 2019 13:52:57 +0000  

We have finally arrived at something public – the recipient uses in this case the service of accommodation from outlook.com ] of Microsoft to handle on-board transportation of their mail. This means that we are about to arrive at something fleshy: outlook.com estimate of the DKIM and SPF domain d & # 39; shipment.

Remember that any change in the body of the e-mail, including a modification or an addition to the headers until now, would have the effect of 39, invalidate the signature. A DKIM rank of outlook.com indicates here that the message comes (probably) from a sender located in the field in the header From: and that It has (probably) not been changed since it left the infrastructure of this area. A failure of DKIM would indicate that the message is completely false or that it was falsified before being received by the outlook.com .

Fourth group: results of DKIM, SPF and DMARC

  Authentication-Results:  spf = pass  (IP of the sender is
smtp.mailfrom = aol.com; destination domain redacted;  dkim = pass  (the signature was
verified) header.d = aol.com; recipient domain written; dmarc = pass the action = no
header.from = aol.com; compauth = reason for the password = 100
Received-SPF: Pass (protection.outlook.com: the domain of aol.com designates as authorized sender) recipient = protection.outlook.com;
client-ip =; helo = sonic306-30.consmr.mail.bf2.yahoo.com;
Received: from sonic306-30.consmr.mail.bf2.yahoo.com ( by
CO1NAM03FT022.mail.protection.outlook.com ( with Microsoft SMTP
Server (version = TLS1_2, number = TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id
15.20.1987.11 via frontal transport; Tue, 06 Aug 2019 13:52:57 +0000
DKIM-Signature: v = 1; a = rsa-sha256; c = relaxed / relaxed; d = aol.com; s = a2048;
[potentially identifying information redacted] 

This is the header of outlook.com detailing his SPF / DKIM rating of the message sent. The message purported to come from a user from redacted@aol.com . The SPF record for aol.com includes SPF records from and yahoo.com 's servers as well as the server that outlook.com ] received the message from – 74.6 .132.229 – is a Yahoo mail server, so the message passes SPF validation.

More importantly for us, we find that the DKIM audit has also been validated. This means that we can be pretty sure that the message in question comes from an email account @ aol.com – it was signed by a legitimate mail server aol .com on his account. output, and was (probably) not manipulated in transit between the networks aol.com and outlook.com .

Fifth group: the MTA who received the message for the first time, and the MUA who sent it

  Received: from sonic.gate.mail.ne1.yahoo.com by
 sonic306.consmr.mail.bf2.yahoo.com with HTTP ; Tue, 06 Aug 2019 13:52:55 +0000

Date: Tue 06 Aug 2019 13:52:55 +0000 (UTC)
From: shipper redacted 
Recipient Redacted 
   Subject: Redacted 

Although we read it for the last time, it is the first first headers pasted on the mail original electronic, updated by the Yahoo webmail server that received it from its original source.

Yahoo's server did not receive the message via a MUA using the standard SMTP protocol; instead, she created the message from the input received on a Web application, as indicated by the line with HTTP in the header.

The of to ] and Subject The lines are usually created by the one who wrote the original message and are generally not very reliable. There is no protocol inherent in the SMTP protocol that prevents you from pasting potus@whitehouse.gov or similar in the field of .

But in this case, we have already verified that the of: claims a from Aol.com . address, and that outlook.com received the message from a mail server that aol.com is authorized to send e-mail @ aol.com . As we can also see that it was signed with a private key that only aol.com should have, we can be pretty sure that it comes from where it says it and that its content has almost certainly not been manipulated.

AOL does not allow you to monkey with From: address to send an email; their interface allows you to use only a "screen name" under your control. This can be the main screen name of your account or one of the other six names that can be added or removed at will. The e-mail address of each nickname is a fully operational e-mail address linked to the user's account and its personally identifiable information. This would be good news for anyone who is willing to summon an ISP to identify a harassing shipper.

Finally, Yahoo's webmail server tells us a little more about the device connected to its web application to create and send the message:

  MIME-Version: 1.0
Content type: multipart / alternative;
border = "---- = _ Part_redacted"

X-Mailer: WebService / 1.1.13837 aoljas Mozilla / 5.0 (iPhone;
IPhone OS CPU [redacted] as Mac OS X) AppleWebKit / [redacted version number] (KHTML,
as Gecko) Version / [redacted] Mobile / [redacted] Safari / [redacted]  

The header X-Mailer adds the information User-Agent of device that contacted the Yahoo webmail server. In this case, the information points to an end user using an iPhone to send the message. In some cases, you can see the IP address of the end user who sent the message. in this case, Yahoo / AOL has decided to protect this information – the service itself knows what IP address was being used by the end user's device, but it is unlikely that it will inform the recipient without a valid subpoena.

One of the big problems with scanning e-mail headers is that they can also be falsified by malicious servers during the process. You always know that the topmost header of a raw email is absolutely added by your own mail server, since it was the latest in the chain . But beyond that, any malicious mail server could have freely changed the header information of the servers that preceded it.

In this case, DKIM gives us a lot more confidence in the validity of the headers that interest us the most. Given that the recipient here uses outlook.com as a perimeter transport for his electronic mail, and outlook.com validates the DKIM signature of the email he receives, we know that the entire contents of the e-mail message, including the headers located below the lower header of outlook.com should be valid .

That said, we can only rely on the DKIM pass if are those who use outlook.com as shipments, and we can verify that all server headers over outlook.com belong to our trusted infrastructure. If you are involved as a third party, you can and should take the DKIM signature (which was present, but we extracted these sample headers) and check it against the entire contents of the 39; e-mail, including the headers below, using the public key of the sender (which may be searched in the public domain of the sender facing the DNS).

In the absence of DKIM signatures, we could not trust any headers below those preceded by our own mail servers – or even, necessarily, the email content itself – and would require a lengthy procedure to manually contact the operators of each mail server along the way, asking if the header lines corresponding to the corresponding entries in the logs of their server SMTP.

Is it enough to identify the person who sent it?

You very seldom can get enough information from email headers to positively identify a sender. The goal usually is to reduce the number of potential senders and to identify the exact information you would need to ask an ISP through a subpoena. If we were to positively identify the shipper in this case, we would have the potential to apply for a court order to obtain additional information from two entities: Yahoo and AOL.

Given the identifier of the message (redacted here), the receipt timestamp, and the name of the mail server, Yahoo would be able to provide the IP address used by the device that sent the message. This IP address could then be linked to a particular ISP, and the latter could be summoned to identify the billing information of the user to whom that IP address was assigned at the time of message creation. If the IP address provided by Yahoo is an unsecure Web proxy, it is a useless impasse; but if it's an end-user IP address, it will provide a reasonably strong correlation to the customer to whom the account has been assigned.

In this case, the message came from an AOL user and we can be pretty certain that the sending address is a screen name associated directly with a account, a lawyer may instead (or in addition) try to assign AOL to the customer information associated with that screen name.

None of this information, the sending IP address, or the main screen name of the AOL client who sent it – is, in itself, an indisputable smoking gun. But they can be strong evidence to help build a case.

About admin

Check Also

Twitch acquires IGDB to better index the games broadcasters are playing

Twitch now owns and operates the Internet Games Database. Amazon’s livestreaming company acquired the IGDB …

Leave a Reply

Your email address will not be published. Required fields are marked *