SMTP: About Envelopes And Letters

Social Engineering, in the context of information security, refers to psychological manipulation of people into performing actions or divulging confidential information. A type of confidence trick for the purpose of information gathering, fraud, or system access, it differs from a traditional “con” in that it is often one of many steps in a more complex fraud scheme.
— Wikipedia

Social Engineering and phising attacks use emails to gather information from the victim. Sometimes employees get emails from their (pretended) manager, sometimes users get emails from their banks, a parcel serveice or even the CEO of Google.

I got such an email from Sundar Pichai. He wrote that I have been selected for using (new ?) Google services. Hooray!
Of course, this mal was not from the “real” Sundar Pichai, even if the mail seem to come from a Google(.org) email address.

Let’s take a closer look at the SMTP header of this email and analyze it. Please note the bold email addresses and domain names:

Authentication-Results: spf=softfail (sender IP is 203.14.228.8)
 smtp.mailfrom=google.org; armix.net; dkim=none (message not signed)
 header.d=none;armix.net; dmarc=fail action=none
 header.from=google.org;node.one; dkim=none (message not signed)
 header.d=none;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
 google.org discourages use of 203.14.228.8 as permitted sender)
Received: from mailrelay.monashhealth.org (203.14.228.8) by
 AM5EUR03FT014.mail.protection.outlook.com (10.152.16.130) with Microsoft SMTP
 Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id
 15.1.587.6 via Frontend Transport; Mon, 5 Sep 2016 16:53:49 +0000
Received: from User (server.ma-rencontre.org [199.115.228.157])
 (user=wba@monashhealth.org.au mech=LOGIN bits=0)
 by SHCLAFM03.southernhealth.org.au with ESMTP id u85GnN9n029599-u85GnN9p029599;
 Tue, 6 Sep 2016 02:49:24 +1000
Message-ID: <201609051649.u85GnN9n029599-u85GnN9p029599@SHCLAFM03.southernhealth.org.au>
Reply-To: <gf.grant01@gmail.com>
From: Google Inc. <donotreply@google.org>
Subject: Re: XKPJGTXUTU
Date: Mon, 5 Sep 2016 09:49:36 -0700
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary=” — — =_NextPart_000_0064_01C2A9A6.5B14EEC8"
X-FEAS-AUTH-USER: wba@monashhealth.org.au
To: Undisclosed recipients:;
Return-Path: donotreply@google.org

There are some problems with classical emails, as you can see in the example above:

1. Anybody can use any email address for sending emails. Just open a telnet session on port 25 of an email server and send a mail from any sender address. Most mail transfer agents (MTAs) won’t check the sender addresse.
2. Mail servers and mail clients use diffenent fields. Mail servers work with the envelope (mail from, rcpt to) of the email, while mail clients use the header field (from, to).
3. Email validation/authentication systems are not used by any domain and not all mail servers / mail transfer agents verify the email address of the sender. The following sender address verification possibilities exist:

• Sender Policy Framework (SPF) — SPF uses policies to speciiy the systems permitted to send messages for the given domain. SPF uses DNS TXT records to publish these policies.
• DomainKeys Identified Mail (DKIM) — DKIM provides for two distinct operations, signing and verifying. Either of them can be handled by a module of a MTA. The MTA can query the DNS TXT record selector._domainkey.senderdomain.com to verify the DKIM signature of an email.
• Domain-based Message Authentication, Reporting and Conformance (DMARC) — DMARC is built on top of SPF and DKIM. It allows the administrative owner of a domain to publish a policy on which mechanism (DKIM, SPF or both) is employed when sending email from that domain and how the receiver should deal with failures. Additionally, it provides a reporting mechanism of actions performed under those policies. It thus coordinates the results of DKIM and SPF and specifies under which circumstances the from header field should be considered legitimate.

Summing up one can say that you can’t trust your mail client. Spoofing a sender email address is still as easy as it was 30 years ago. We have to wait until the majority of the mail servers implemented the verification systems outlined above.