This blogpost will explain how to read and understand the email header which travels with every email. It contains details about the sender, taken route and the receiver. Use this information to avoid unwanted emails or to recognize a scam or malware delivered by email.
How to access the Email Header
In the Mailfence web interface, go to your mailbox, right-click on the email, select ‘View source’.
However, most mail clients allow access to the message header. The following list contains a few popular email and webmail clients. In case not listed here, please refer to the manual of your client.
View the Email Header in Google Mail (Gmail) Webmail:
Login to your account via the web-interface and open the message (click on it). Click on the ‘down-arrow’ on the top-right of the message and select ‘Show Original’.
View the Email Header in Yahoo Mail Webmail:
Login to your account via the web interface and open the message (click on it). Click on ‘Actions’ and select ‘View Full Header’.
View the Email Header in Hotmail Webmail:
Login to your account via the web interface and go to the message list. Right-click on the message and select ‘View Message Source’.
View the Internet Headers in MS Outlook:
Open the message in MS Outlook. Now go to ‘View’ and select ‘Message Options’ – or ‘File’ -> ‘Info’ -> ‘Properties’. Check ‘Internet Headers’.
View the Email Header in Thunderbird:
Open the message, then click on ‘View’ and select ‘Message Source’.
View the Email Header in MS Windows Mail (and MS Outlook Express):
Select the message in the list, right-click on it and select ‘Properties’ and go to ‘Details’.
Note: instructions mentioned above may vary depending on the version of the email client that you are using.
How to use Email Header Fields
We will use the following sample message header. The font in blue will describe what each of the common fields in an email header represent, and how this information can be used in a useful manner.
Standard Email Header Fields
Received: from sender_mail_server ([bbb.bbb.bbb.bbb]) by recipient_mail_exchanger (envelope-from <example@gmail.com>) with ESMTPS
The message was received by the recipient_mail_exchanger from sender_mail_server with an IP address bbb.bbb.bbb.bbb over STARTTLS (‘S’ in the ESMTP tag means secure).
for <example@mailfence.com> ; Wed, 7 Sep 2018 12:35:32 +0200 (CEST) Return-Path: example@gmail.com
The mail server sends a notification email to the address specified here, when the message bounces or cannot be delivered. This email address is different from the sender’s one and it results as “reply to” address.
Received: by xyz.google.com with SMTP id abc.xyz for <example@mailfence.com>; Wed, 07 Sep 2018 03:35:32 -0700 (PDT)
Standard Email Header Fields (continued)
The message travels through all of these (usually 1-3) mail servers (or MTA’s) from sender_mail_server to the recipient_mail_exchanger.
Received: from ‘Sender_display_name’ ([aaa.aaa.aaa.aaa])
The message sent from the sender’s device with the IP address aaa.aaa.aaa.aaa. Located in the X-Originating-IP header field. In order to respect email clients, privacy removes the IP address, as it reveals sender’s location details.
by sender_server_domain_name with ESMTPSA id abc_xyz_123 for <example@mailfence.com> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 07 Sep 2018 03:35:31 -0700 (PDT)
The sender_server_domain_name mail server after receiving a message from the sender’s device with IP address ‘aaa.aaa.aaa.aaa‘, transfers the message over STARTTLS (in the ESMTP tag, ‘S’ means secure and ‘A’ means authenticated). Information also includes the TLS version and cipher-suite that was used by the STARTTLS protocol.
Some might try to fake the routing information, and your mail server is supposed to give you a warning that something was not correct during the transfer from sender_server_domain_name to the recipient_mail_exchanger.
From: example@gmail.com
Message sender address.
This could easily be faked, or could be made like examp1e@gmail.com OR example@gmai1.com (‘1’ and ‘l’ being very similar).
Check our phishing and social engineering blogposts for more details.
To: example@mailfence.com
Message receiver address.
Subject: Leaving Gmail!
Message subject.
Date: Wed, 7 Sep 2018 12:35:29 +0200 Message-ID: 000601d30978hc36040$819a20c0$@gmail.com
Date and Message ID.
If the date mentioned here differs from the date mentioned in the last received header (top one), then it could indicate possible message delivery issues OR an MITM attack. Therefore we advice to pay caution in such cases.
MIME-Version: 1.0 Content-Type: multipart/alternative;
MIME Version and Type.
X-Mailer: Microsoft Outlook 16.0
This message sent by the client email (or MUA) . In order to respect the email clients, privacy removes this line.
Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a multi-part message in MIME (Multipurpose Internet Mail Extensions) format. It is an Internet standard that extends the format of email messages to support rich text, files and other active content.
<<Message body>>
Hello, Enough of privacy violations and shady business practices by Gmail! This is my last email from Gmail, as I finally decided to join Mailfence! Regards, Privacy conscious user! ------=_NextPart_000_0007_01D44514.EEC24AC0...------=_NextPart_000_0007_01D44514.EEC24AC0-- ...
<<Message body>>
Message body might contain bad links like ‘example.com’ which could be hyperlinked to ‘maliciouslink.com’.
Check phishing and social engineering blogposts for more details.
Sender Policy Framework (SPF)
SPF is a framework to prevent sender address forgery. In addition this platform describes mail servers that are allowed to send messages for given (sender) domain. SPF thus helps to avoid fake sender email addresses. The result (Received-SPF) can be neutral, pass or fail.
From the sample message above:
Received-SPF: pass
Validation results is ‘pass’ since sender_server_domain_name IP address sends emails for ‘gmail.com’ domain.
If the validation result is ‘fail’, then it is highly likely that someone tried to spoof the sender’s email address and/or content.
Mailfence supports SPF and also encourages custom domain users to set one.
Domain Keys Identified Mail (DKIM)
DKIM is a method to associate a domain name to an email. Furthermore it allows an organization to check the (cryptographic) signature to ensure untampered transit of the message. Thereby it ensures the ownership of the message.
From the sample message above:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20161025;
h=from:to:subject:date:message-id:mime-version:thread-index
:content-language;
bh=fZjxO4TdlsVYWA6YIXoMF8AS+FOsm2lV1tfhDvYZNQo=;
b=cMSUNWMGENp4jXuFTInBnZi6Sq2ZcjhBNA0ht8rSEt1SR8b0gGmiiZZ4l52lGSCum5
lRtmPPtt/tgnqubiLBBW2fatlarhjo6qRp7FRE9IsE6XBIl6muTGS/kUDwEm9NGXjQRp
nxmHp4/JKDKrYHg8cKsm+yr3k17hNXHITIrb9VAh2CtEKpAxSYN3MsC4QplXdnLArQju
U3jAnJf0lLZwZcygBbZSY7ENEAtHSbHpt6LLeQKlzosYARoakAH3j8EaAAAu1TfyAYE4
+u7ENqUzddifO6Qty3E2I4Soq00SbOO+e64WIUZ0gxoARQqeuAN7H/jaOkC4t5mhWmkb
aEFA==The message contains a valid DKIM signature (formatted as per the standard).
dkim=pass
Validation results is ‘pass’.
If the validation result is ‘fail’, then it is highly likely that the message was spoofed or modified during transit and/or that the message is spam.
Mailfence supports DKIM for regular users by default. Also we encourage custom domain users to use it.
Spam score
Commonly used spam detection programs (e.g., SpamAssassin) installed on the mail servers provides a detailed report for each message. They do this by adding lines and a summary in the message header.
X-Spam-Flag: NO
Spam detection result.
X-Spam-Status: No hits=-1.2 required=4.7
Spam detection result along with the score. A score less than 5 means (on most systems) not spam, between 5 and 15 probably spam, and more than 15 definitely spam.
symbols=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,RDNS_NONE,SPF_PASS device=ccc.ccc.ccc.ccc
Spam detection programs do not only check the message sender, but also check message format and the content of the message in order to derive their final spam score. E.g., message structure, SPF+DKIM, DNSBL, custom rules…
If the overall spam score is between 5 and 15 or more than 15, then it is highly likely that the message is suspicious or a spam. However, recipient_mail_exchanger makes the final decision.
On the email headers exist many other approved message header fields as well as non-standard/custom message header fields. Some examples are:
- Authentication-Results – summary of sender_server_domain_name authenticity (based on SPF, DKIM and other results).
- List-ID – an email mailing list reference
- List-Unsubscribe – a direct reference used to unsubscribe from a mailing list.
- Auto-Submitted – indication that a system generated the message (e.g., notification messages, …)
- …
Email Header Fields and End-to-end encrypted messages
Email message header fields are mostly read independently of the message body. Thus which is end-to-end encrypted and is meant to be read by the client (e.g., who holds the private key in a Public key crypto-system). However, following are some of the common message header fields that can indicate an encrypted and/or signed message.
From the sample message above:
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature" .... Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature Content-Disposition: attachment
Indicates a MIME type ‘multipart/signed’ for OpenPGP signed message which is sent as an attachment. OpenPGP signatures can also be sent inline (not as an attachment).
Content-Type: multipart/encrypted; protocol="application/pgp-encrypted"; ... Content-Type: application/octet-stream; name=encrypted.asc Content-Transfer-Encoding: ... (base64, 7bit, ...) Content-Description: OpenPGP encrypted message Content-Disposition: inline; filename=...
...
Indicates a MIME type ‘multipart/encrypted‘ for OpenPGP encrypted message which is sent as an attachment. Send OpenPGP encrypted messages inline (not as an attachment).
-----BEGIN PGP SIGNATURE----- ... -----END PGP SIGNATURE-----
Indicates the beginning and end of an OpenPGP signature.
-----BEGIN PGP MESSAGE----- ... -----END PGP MESSAGE-----
Indicates the beginning and end of an OpenPGP encrypted message.
Protecting email headers from end-to-end encryption
Use end-to-end encryption and digital signatures to further check the legitimacy of message headers.
Mailfence includes the From, To and Time-stamp fields in the message body before signing and/or encrypting it. This provides a way for the recipient to check:
From: example@gmail.com
To: example@mailfence.com
Sep 7, 2018 12:35:29
- If message From and To addresses do match with the sender and recipient addresses included in the signed and/or encrypted message body. Therefore, this helps in detecting any possible spoofing of sender/recipient address.
- If the message sending date matches (or is significantly close) with the time-stamp included in the signed and/or encrypted message body. This helps in detecting a possible message replay attack.
For instance including the actual message header fields inside an encrypted message body can also help in preventing meta-data leaks (e.g., Protected email headers).
Many third party message header analyzer tools (https://testconnectivity.microsoft.com/, https://toolbox.googleapps.com/apps/messageheader/, https://mxtoolbox.com/EmailHeaders.aspx, …) produce an easy to read report from that message header data. However, please note that you will have to share your message header with these services…
Mailfence is a secure and private email-suite that provides users full control over their data.
Follow us on twitter/reddit and keep yourself posted at all times.
