1

Premise: I know pretty well how SMTP works, and how to read an e-mail header. I know what all the main fieds mean, but I couldn't know what to look for if I want to know if the mail is kind of malicious (e.g. spoofed).

For instance, given the following e-mail header:

Delivered-To: damore@dis.uniroma1.it
Received: by 10.170.153.138 with SMTP id u132csp362868ykc;
 Wed, 18 Jun 2014 22:23:12 -0700 (PDT)
X-Received: by 10.224.162.212 with SMTP id w20mr2259156qax.50.1403155391885;
 Wed, 18 Jun 2014 22:23:11 -0700 (PDT)
Return-Path: <nazaret.galilea@archaeologist.com>
Received: from mout.gmx.com (mout.gmx.com. [74.208.4.200])
 by mx.google.com with ESMTPS id s2si5075397qak.63.2014.06.18.22.23.11
 for <damore@dis.uniroma1.it>
 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Wed, 18 Jun 2014 22:23:11 -0700 (PDT)
Received-SPF: none (google.com: nazaret.galilea@archaeologist.com does not designate permitted sender
 hosts) client-ip=74.208.4.200;
Authentication-Results: mx.google.com;
 spf=neutral (google.com: nazaret.galilea@archaeologist.com does not designate permitted sender
 hosts) smtp.mail=nazaret.galilea@archaeologist.com
Received: from [68.146.72.33] by 3capp-mailcom-lxa14.server.lan (via HTTP);
 Thu, 19 Jun 2014 07:21:59 +0200
MIME-Version: 1.0
Message-ID: <trinity-10a5ee53-e71d-4b2c-a69f-f9624b154874-1403155319290@3capp-mailcom-lxa14>
From: "Luis Gutierrez" <nazaret.galilea@archaeologist.com>
To: Marina.Scheidler@bibliothek.uni-augsburg.de
Subject: Prayer
Content-Type: multipart/mixed;
 boundary=rehcsedm-e54a6372-422a-4dea-b91c-2abd856af2a4
Date: Thu, 19 Jun 2014 07:21:59 +0200
Importance: normal
Sensitivity: Normal
X-Priority: 3
X-Provags-ID: V03:K0:QOIMVsTNJekpMbcCkjuHDVKatYQZ9wC72dFJEb42vaY
 hpFhr7gaVuWuGGISumdLEpXf3yn7rQNF6ZRch1TfS9J1I82cn/
 u8UZnJMu7NwE9SNzrL4avNN77Lc1MjCsJGmKt62nErj508xvdo
 AyldimzoGxZywT4eMoeFTJCClcOn9ocBHowp6Esp1gRwGuUJzb
 5MP9bB4PYKy8y1aieZSDoM2VY8QXaWW2HoBfUILeE9+/fVmVV3
 2sQnA9c60YjGUDB3sscOBcB7Exa1DhmJ1km3cMDIfozBWKhji3
 UothB/8EHOkdD8giw1WZZGHvdEX

--rehcsedm-e54a6372-422a-4dea-b91c-2abd856af2a4
Content-Type: text/html; charset=UTF-8

(it is taken from an university exercise, so I know that there must be something)

The only interesting thing that I found is that contents of fields Delivered-To: and To: are different (how is it possible?).

What else should I look for?

Improve this question

2 Answers 2

Reset to default
2

Frankly, this mail header looks strange for me in several places and I'm not sure if this is because it was actually delivered this way, if it was changed afterwards or if the mails was just constructed:

  • The Received-SPF and Authentication-Results fields claim to be set from google.com but are located after the Received field for google.com. According to RFC 7208 9.1 and RFC 7601 4.1 these fields must be placed on top of the mail before the Received header of the specific MTA.
  • The Received header from google.com claims that the mail was received from mout.gmx.com but the mails does not include a matching Received header for GMX.
  • And finally the problem what this exercise was probably mainly about: the recipient according to the Received fields was damore@dis.uniroma1.it but the recipient according to To: is Marina.Scheidler@bibliothek.uni-augsburg.de. While this could be possible if there is a forwarding installed from Marina.Scheidler@bibliothek.uni-augsburg.de to damore@dis.uniroma1.it this should show up in the Received headers.

But again, this mail looks strange for me in many places and I rather suspect that it was somehow constructed to demonstrate something, only it was constructed incomplete and wrong.

Improve this answer
5
  • Thank you so much, I think I'm going to accept this answer, in the absence of a better one. Anyway, my question was intended to be more generic: I would appriciate if you expanded the answer adding more things to be careful with (even not related to the specific example).
    – user402843
    Mar 31, 2019 at 10:34
  • Furthermore, I noticed that the first Received: is 68.146.72.33 -> 3capp-mailcom-lxa14.server.lan, while the second is mout.gmx.com -> mx.google.com. So 1) Aren't we missing a hop? 2) Is 68.146.72.33 the actual sender's device IP address or something else?
    – user402843
    Mar 31, 2019 at 10:44
  • 1
    @user402843: " Aren't we missing a hop?" - this is exactly my second point.
    – Steffen Ullrich
    Mar 31, 2019 at 11:47
  • 1
    "I would appriciate if you expanded the answer adding more things to be careful with" - There are some many things, like DKIM, DMARC, SPF, adherence to standards, order of headers, mismatch between headers ... - this would be too broad. Moreover many valid mails are actually more or less broken regarding the standards so many assumptions that something is wrong has to be taken with caution.
    – Steffen Ullrich
    Mar 31, 2019 at 11:49
  • Sure, I skipped it. Well, thank you so much!
    – user402843
    Mar 31, 2019 at 13:38
2

I found something of your interest :

  • The sending IP address and the SPF validation will give you a very good sense of whether an email truly comes from the person purported to be sending it.
  • The line Received: from mout.gmx.com (mout.gmx.com. [74.208.4.200]) gives you the IP address from where the email is coming from.
    Now, there are various websites that give threat intelligence reports such as VirusTotal. If you search about this IP address you will get an interesting report See this!
    The above address is reported by 2 firms also it's community score is quite shocking.
Improve this answer
1
  • 1
    Given that this mail is from 2014 I would not rely on any reports which are done 5 years later. Also, SPF result is none in this case, i.e. the claimed sender domain did not publish any SPF policy so nothing could be checked. This means one cannot rely on SPF either.
    – Steffen Ullrich
    Mar 30, 2019 at 20:28

You must log in to answer this question.

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