You can alter the contents of an .eml file and leave the header intact...

There's a small conversation about whether DKIM signatures prove that the Wikileaks emails haven't been altered. Somebody said to show that the contents could be altered without affecting the header, so I thought I'd try. Here's what I came up with:

To replicate:

1) Take a .eml file from the Wikileaks archive.
2) Open it with Notepad
3) Replace the content of the message with whatever you want
4) Open it with your mail client (Outlook for me)


I don't have the ability to run the type of check found here:

http://dailycaller.com/2016/10/21/heres-cryptographic-proof-that-donna-brazile-is-wrong-wikileaks-emails-are-real/

But maybe somebody else can. I'm pretty sure, though, that I've altered the contents of the email and left the header intact, which in theory means that from a technical perspective, once Wikileaks had the emails in their possession, they could have done the same.

I need to reiterate, though, you would have to be incredibly short-sighted to do that. There are multiple copies of this email record in existence - at least one in the mailboxes of everyone on this thread, as well as any backups that people might have. To alter your copy and then expect that no one would point it out would be optimistic in the extreme (delusional, really). I think that a reasonable person would start with the hypothesis that these aren't altered based on Wikileaks' record of document integrity, the fact that other evidence is corroborating what's found in the emails (Project Veritas' videos naming the time of a meeting that's found in the email archive, etc.), and other evidence. But that's just my opinion.

What do you think? Again, I'm not an expert in this area, so comments are welcome.

Here is the header:

Delivered-To: john.podesta@gmail.com
Received: by 10.25.88.78 with SMTP id m75csp262190lfb;
        Sat, 13 Feb 2016 12:46:34 -0800 (PST)
X-Received: by 10.98.34.212 with SMTP id p81mr12085412pfj.23.1455396394008;
        Sat, 13 Feb 2016 12:46:34 -0800 (PST)
Return-Path: <gbsperling@gmail.com>
Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com. [2607:f8b0:400e:c03::236])
        by mx.google.com with ESMTPS id tw2si28165283pab.238.2016.02.13.12.46.33
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Sat, 13 Feb 2016 12:46:33 -0800 (PST)
Received-SPF: pass (google.com: domain of gbsperling@gmail.com designates 2607:f8b0:400e:c03::236 as permitted sender) client-ip=2607:f8b0:400e:c03::236;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of gbsperling@gmail.com designates 2607:f8b0:400e:c03::236 as permitted sender) smtp.mailfrom=gbsperling@gmail.com;
       dkim=pass header.i=@gmail.com;
       dmarc=pass (p=NONE dis=NONE) header.from=gmail.com
Received: by mail-pa0-x236.google.com with SMTP id yy13so61924271pab.3;
        Sat, 13 Feb 2016 12:46:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=content-type:mime-version:subject:from:in-reply-to:date:cc
         :content-transfer-encoding:message-id:references:to;
        bh=+28QEQtUrTV+f7iNbIkhVKqZcL0gVrkNHD6d1ZjaavY=;
        b=Mh7fFtVDRubr099eA7VuhM4HhOlpuFXt+BReEPEFiM5dv9RymdXGMxRxvS6O1/2k/w
         ZusjQ0i7nOCo/Ui+9RCR2Qo0fSh/fi0aIxRzc2etoh7YTw4AFFJrNZdAf6/7l1Yw6WfC
         IfH5O0IjS7ovAWg3ZoW4BNocux+YANHMJWTEUA3yNZaEBvMX+O4oGZcvVs95oEAMbrBm
         ZYlgycUeBk+xHDypyBN7nW3VqcRy2i3ghaICVSYjHel512wlhj0DxgbhgSTPhJ4wpnRp
         QwzL325IAuCFIdJ1Ukg5kMWwcfZCFK8Gt1ixH0Y8qkjXVxecNgAHfx1L5jrXvo2pVh1Z
         zQIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:content-type:mime-version:subject:from
         :in-reply-to:date:cc:content-transfer-encoding:message-id:references
         :to;
        bh=+28QEQtUrTV+f7iNbIkhVKqZcL0gVrkNHD6d1ZjaavY=;
        b=h50Po3S/ek8QAME11e2e7TcQMO/NVtGC2QXvpdKjsi8sbTwLSEZbvCXCIww7ocpbzP
         OJYWlEf6P3vAtYgm7WVbJRS5L1B5UfrGEShGwqmMkBBi5tSer+K3D7/i+MUo89f5Zb+b
         p3yiE61ot1mPViPMISSMC8ryXdcnmUrOqbZpC2nZ1lhmctOVOAT1aIhj8xgVxKt4pGQa
         3SMCE6NqD3wZT35W+7YiY82BaufAMcRozK32fVBbw3fUykDosney0uJ0JNeyVVOlruUn
         ZpleGXUODOJhip4+eWCc4MrlskvKsCOVrgocK+J5vJ4Lwmmo94CPigZC1V2cQphy/IUb
         FOaw==
X-Gm-Message-State: AG10YOQv1YZaF42PVZtmmnowAjY0DGo9TEdkv2gr9pAcIZhLLyaGmFDsUkzQBVvWWsO3bQ==
X-Received: by 10.66.248.198 with SMTP id yo6mr12033964pac.54.1455396393361;
        Sat, 13 Feb 2016 12:46:33 -0800 (PST)
Return-Path: <gbsperling@gmail.com>
Received: from [192.168.1.8] (27.sub-70-211-16.myvzw.com. [70.211.16.27])
        by smtp.gmail.com with ESMTPSA id z5sm28115282pas.29.2016.02.13.12.46.31
        (version=TLSv1/SSLv3 cipher=OTHER);
        Sat, 13 Feb 2016 12:46:32 -0800 (PST)
Content-Type: multipart/alternative;
boundary=Apple-Mail-12C54A17-2C76-441A-AAA3-DB0AF4C35185
Mime-Version: 1.0 (1.0)
Subject: Re: HRC financial proposal
From: Gene Sperling <gbsperling@gmail.com>
X-Mailer: iPhone Mail (12B436)
In-Reply-To: <5495322817735053152@unknownmsgid>
Date: Sat, 13 Feb 2016 12:46:31 -0800
CC: Neera Tanden <ntanden@gmail.com>, Mike Schmidt <mschmidt@hillaryclinton.com>,
 John Podesta <john.podesta@gmail.com>,
 Michael Shapiro <mshapiro@hillaryclinton.com>,
 David Kamin <davidckamin@gmail.com>, Michael Pyle <pyle_michael@yahoo.com>
Content-Transfer-Encoding: 7bit
Message-Id: <F771A0FC-6079-4647-8815-0C5A92AF8651@gmail.com>
References: <56BF87F601DA055A00F5017D_0_32030@p171> <7B124F68-F1AD-43E3-A9EA-0489FAC8B0D3@americanprogress.org> <CAJiTYQaXk1PO2E46BLgu+UbeVg917Nj_yM_CAC8F3pW_7-V=6g@mail.gmail.com> <5495322817735053152@unknownmsgid>
To: Jake Sullivan <jsullivan@hillaryclinton.com>

--Apple-Mail-12C54A17-2C76-441A-AAA3-DB0AF4C35185
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Two thoughts for discussion:

1. We're the most corrupt people ever - except for the people who might have altered this email.

2. It looks this email could have been altered without affecting the email header.

--Apple-Mail-12C54A17-2C76-441A-AAA3-DB0AF4C35185--

DKIM does not provide protection after message delivery.

This is a very important point, and must be considered in any analysis...

In my opinion you would have to be really, really careless to take an email that has intact headers and then modify just the message content when you knew that the original was sitting out in somebody else's inbox(es), though. To say it simply, you'd have to be beyond dumb to attempt that kind of forgery.

We'll see, though... history is full of people doing really dumb things. Heck, I do three really dumb things a day just to stay humble.

Why Bother Looking at an Email Header?

Love this:

Why Bother Looking at an Email Header?

This is a very good question. For the most part, you really wouldn’t ever need to unless:

• You suspect an email is a phishing attempt or spoof
• You want to view routing information on the email’s path
• You are a curious geek

http://www.howtogeek.com/108205/htg-explains-what-can-you-find-in-an-email-header/

-----------

I'll take door #3...

What does phx.gbl mean (in the Message ID)?

"phx.gbl is an internal Active Directory domain that Microsoft uses to manage datacenter machines.  It gets added to message headers as a way to trace what machines actually saw a message when Microsoft needs to diagnose specific problems.  The name is equivalent to a *.local domain some organizations use for AD management.  It is by design that these machines are not addressable from the internet as part of Microsoft's defense in depth security planning."

Jomi Schell, Principle Developer Lead

Updated 24 Dec 2011 · Upvoted by Martin Handwerker, Development Manager at Microsoft for a decade and Anjor Hemant, Software Engineer at Microsoft

https://www.quora.com/Network-Protocols-Where-does-phx-gbl-in-all-Microsoft-e-mail-headers-derive-from

To Whom Was the Email Sent?

Answer: "podesta@law.georgetown.edu" <podesta@law.georgetown.edu>

It appears that the reason the email ended up in the Wikileaks archive is that somebody had set up Mr. Podesta's Georgetown emails to automatically forward to his Gmail account.

Was the MessageID of the email a valid Microsoft MessageID?

Answer: Although it can't be determined conclusively (meaning I don't have access to all the emails in the world to make sure this is a unique id) the message id does follow Microsoft naming conventions and appears to be valid...

Link to tool I used to perform analysis:

Using Message ID to see if message was forged

What was the MessageID (the unique identifier) of the email?

<SNT150-W75F932A59B6A19648914E9C31D0@phx.gbl>

How Many Hops Did The Email Take?

Answer: 7

How Long Did it Take For the Email to be Delivered?

Answer: Delivered after 7 seconds

When Was the Email Created?

Answer: 11/16/2015, 11:40:57 PM

IP discrepancy

What does X- mean in an email header?

RFC822 ("Standard for the Format of ARPA Internet Text Messages") specified in sections 4.7.4 and 4.7.5 that headers beginning with "X-" would not ever be part of any standard, and thus can be used for application-specific purposes.

For what it's worth, the more recent BCP document RFC6648 ("Deprecating the 'X-' Prefix and Similar Constructs in Application Protocols") recommends that the use of the "X-" prefix be avoided in the future, as the distinction between standardized and nonstandardized headers is not well defined, and attempting to draw such a distinction fails when commonly used nonstandard headers are adopted as standards.

Why were the first two servers in the chain on blacklists?

What does X-Microsoft-Exchange-Diagnostics-untrusted: 1 mean

can't find the documentation...

X-ORIGINATING-IP not there. Why?

I am trying to find out who is sending me emails by analyzing the email header looking for "X-ORIGINATING-IP", however it has been removed by ms, Is there any other way to get this information?. I have the mail header which contents this info "X-TMN: [MFL/CsAQEKwS6FBaH6erkgcbcjS7fbWLKme6V2pHuA8=]". Can X-TMN be decryp?


From the email header, it does not revealed the client ip and the first received is instead 65.54.190.189 by  BAY180-W50. Not very indicative of the sender real ip. One thing coming back is Microsoft email services like Hotmail, Live, Outlook etc. stopped showing the originating IP late in 2012. The Redmond address is just the Microsoft server.

I tried using http://www.ip-tracker.org/checker/email-lookup.php and minimally this is legit emailaccount e.g. smithvillaclub@outlook.com. I doubt we can drill further to find the ip unless there is something hints from the sender to"beacon" anything back to you...tough nut...or seek authority if that is abusive account suspected...

not easy folk as mentioned as the email header has limited and it will be good to grab or forensic the target machine if this is organisation asset as end user agreement acceptance compliance. another is probably looks at the exchange to sync up event timestamp but tedious ...another is send the target to trace his email - see
http://help.exacttarget.com/en/documentation/exacttarget/tracking/tracking/

http://www.npr.org/2016/10/19/498564674/watch-live-in-third-presidential-debate-trump-and-clinton-make-final-pitch

how do you read a dkim header?

https://www.emailonacid.com/blog/article/email-development/what_is_dkim_everything_you_need_to_know_about_digital_signatures

Here is an example DKIM signature (recorded as an RFC2822 header field) for the signed message:

DKIM-Signature a=rsa-sha1; q=dns;
d=example.com;
i=user@eng.example.com;
s=jun2005.eng; c=relaxed/simple;
t=1117574938; x=1118006938;
h=from:to:subject:date;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb
av+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Let's take this piece by piece to see what it means. Each "tag" is associated with a value.

• b = the actual digital signature of the contents (headers and body) of the mail message
• bh = the body hash
• d = the signing domain
• s = the selector
• v = the version
• a = the signing algorithm
• c = the canonicalization algorithm(s) for header and body
• q = the default query method
• l = the length of the canonicalized part of the body that has been signed
• t = the signature timestamp
• x = the expire time
• h = the list of signed header fields, repeated for fields that occur multiple times

What does dkim=none mean?

Senders insert a digital signature into the message in the DKIM-Signature header, which receivers then verify.

• none = 'The message was not signed'
  This means that the message had no DKIM signature. This is not the same as failing.

https://www.emailonacid.com/blog/article/email-development/what_is_dkim_everything_you_need_to_know_about_digital_signatures

What does dis=none mean in the Authentication Results mean?

dis=none (disposition=none) -- means that Gmail applied "none" policy

http://lists.dmarc.org/pipermail/dmarc-discuss/2013-April/001848.html

missed the Gmail IP...

157.56.111.54
Colorado

what does return-path mean?

Just googled "Return-Path email"

Every e-mail message has a hidden field called the "Return-Path" address (sometimes called a "bounce address" or "envelope sender address"). This should be the address a message really came from, and it's the address to which any undeliverable message notices ("bounces") are sent.

Why are Received and X-Received different?

What is the difference between X-Received and Received in email-header?

Received is a header defined in the standard while X-Received is a non-standard header added by some user-agents or mail transfer agent like the google mail SMTP server.

http://security.stackexchange.com/questions/103563/what-is-the-difference-between-x-received-and-received-in-email-header

Does CH2M Hill have a location near the registered location for their IP?

Yes.

Does it appear to be the same as the location the IP is registered? The Geo-IP isn't pin-prick accurate, but I'd say we're close. Here's why:

1.4 miles away - I'd walk, not drive...

Note that this doesn't PROVE anything. When I use the same tools to find the IP associated with my phone, it drops a pin in a location that's 30+ miles away from my house, which is a major metropolitan area, and where the Comcast servers that service my phone likely are. So take it for what it's worth... just know that we're talking in general areas, here, not specific locations...


Reminder of why this IP is important:

-----------email header info start -----------

Received-SPF: Fail (protection.outlook.com: domain of law.georgetown.edu does
 not designate 141.161.191.75 as permitted sender)
 receiver=protection.outlook.com; client-ip=141.161.191.75;

------------email header info end------------

(for normal people out there, "client" means a piece of hardware - think laptop, phone, server, workstation, etc.)

Who is CH2M Hill? Why don't Georgetown's servers like their IP (141.161.191.75)?

Background: One of the servers that the Wikileaks - Podesta - probablynotaboutScalia email passed through is registered to CH2M Hill, and can be geolocated to a location in Washington D.C. (the coordinates appear to not be precise, as they land in the middle of a park when plotting them on Google Earth).

In the headers it shows that this IP caused the email to fail some tests on its way to its destination:

----------------------

Authentication-Results: spf=fail (sender IP is 141.161.191.75)

smtp.mailfrom=law.georgetown.edu; gmail.com; dkim=none (message not signed)

header.d=none;gmail.com; dmarc=fail action=none header.from=outlook.com;

----------------------

although the email was still delivered successfully

Question: Who is CH2M Hill?

Analysis:

From CH2M Hill's website:

---------------
Many clients, many places, many skills. Through building trusted relationships, we partner with governments, communities, businesses and organizations all over the world.

We are dedicated to tackling our clients’ toughest infrastructure and natural resource challenges with optimism and imagination. Explore all our capabilities, see our projects and connect with us, so together, we can turn challenge into opportunity.

---------------

So they're a big, BIG company. Okay.

Question: why don't Georgetown servers like their IP (141.161.191.75)

IT is hard. You can have one problem and a thousand POSSIBLE reasons it's occuring and a dozen different ways you could fix it.

Here's a POSSIBLE reason the email failed its test (from here):

"It sounds to me like they have an email gateway that is accepting mail from your server and passing it on to their email server and then their server is doing an SPF check. Having their email server do an SPF check on emails that have already been accepted by their email gateway should cause every message that comes through their gateway to fail SPF." 

Could this be the case at Georgetown? Possibly. IS it the case, Who knows? Without talking to the network administrators I think it would be difficult to determine this. So let's ask them. They probably won't answer, but you know, maybe they will!

I'll update this post if I hear back.

Was the email automatically forwarded from Podesta's Georgetown account to his Gmail one?

Question: Was the email automatically forwarded from Podesta's Georgetown account to his Gmail one?

Conclusion: Most likely

The whole delivery chain only took a few seconds (don't have an exact number at the moment)...

In addition, the "Resent From: " header is pretty good evidence that his Georgetown account was set to automatically forward to his Gmail account.

This from an annoyed Gmail user (here):

"Now that the emails are forwarding to my gmail account, though, I have a big old ugly "Resent-From" field (with my name in it) at the top of every header! This is super annoying, is there any way to turn this off?"

It also makes sense that if the email was sent from who it was purportedly sent from that he could have found the Georgetown email fairly easily - the Gmail account, not so much.

Was the From address in the email spoofed?

Question: Was the "From" address in the Podesta-Wikileaks-probablynotaboutScalia email spoofed?

Conclusion: I'm not qualified to make one. All the servers seem legitimate... Microsoft, Georgetown, Google. 

More analysis is needed to understand what happened to the email on it's path from "Send" to "Received"

---------------------------------------------

So the email failed DMARC testing. One of the reasons that can happen is because the from address of the message is spoofed. Is that what happened here? Let's follow along with a tutorial

III. How to I analyze the e-mail headers?

Let's review a real life example: The following e-mail headers are from an e-mail that supposedly arrived from Chase Bank, and is a clear example of phishing attack (click for larger image)

Gosh, I wish I had seen this earlier!

Our From field says: 

From: Joe Patterson <viejojoe@outlook.com>

and there's also a Resent-From in a different part of the header:

Resent-From: <podesta@law.georgetown.edu>

What does our header say in regards to the stuff that's in the "Useful Analysis" portions of that graphic?

Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0054.outbound.protection.outlook.com. [157.56.111.54])

        by mx.google.com with ESMTPS id c196si28806261qkb.1.2015.11.16.21.41.03

        for <john.podesta@gmail.com>

        (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128);

        Mon, 16 Nov 2015 21:41:04 -0800 (PST)

Received: from SN1PR0701CA0016.namprd07.prod.outlook.com (10.162.96.26) by

 BLUPR07MB529.namprd07.prod.outlook.com (10.141.204.141) with Microsoft SMTP

 Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 05:41:01 +0000

Received: from BN1BFFO11FD048.protection.gbl (2a01:111:f400:7c10::1:107) by

 SN1PR0701CA0016.outlook.office365.com (2a01:111:e400:5173::26) with Microsoft

 SMTP Server (TLS) id 15.1.325.17 via Frontend Transport; Tue, 17 Nov 2015

 05:41:01 +0000

Received: from mail.law.georgetown.edu (141.161.191.75) by

 BN1BFFO11FD048.mail.protection.outlook.com (10.58.145.3) with Microsoft SMTP

 Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 17 Nov 2015 05:41:01

 +0000

Resent-From: <podesta@law.georgetown.edu>

Received: from na01-bn1-obe.outbound.protection.outlook.com (141.161.191.14)

 by LAW-CAS2.law.georgetown.edu (141.161.191.21) with Microsoft SMTP Server

 (TLS) id 14.3.248.2; Tue, 17 Nov 2015 00:41:00 -0500

Received: from BLUPR07CA082.namprd07.prod.outlook.com (10.160.24.37) by

 BLUPR07MB529.namprd07.prod.outlook.com (10.141.204.141) with Microsoft SMTP

 Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 05:40:58 +0000

Received: from BL2FFO11FD014.protection.gbl (2a01:111:f400:7c09::110) by

 BLUPR07CA082.outlook.office365.com (2a01:111:e400:8ae::37) with Microsoft

 SMTP Server (TLS) id 15.1.331.15 via Frontend Transport; Tue, 17 Nov 2015

 05:40:58 +0000

Received: from SNT004-OMC1S4.hotmail.com (65.55.90.15) by

 BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222) with Microsoft

 SMTP Server (TLS) id 15.1.325.5 via Frontend Transport; Tue, 17 Nov 2015

 05:40:58 +0000

Received: from SNT150-W75 ([65.55.90.9]) by SNT004-OMC1S4.hotmail.com over TLS

 secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 16 Nov 2015

 21:40:57 -0800

X-TMN: [dTeiFt+mIlzCgMdOmxQpdxSi3rWYMV/J]

X-Originating-Email: [viejojoe@outlook.com]

None of the stuff from the bottom box - not sure why that would be.

Let's do an analysis like the one the tutor did:

ANALYSIS:

• The message claims that it was sent from Joe Patterson <viejojoe@outlook.com>. This information can be very easily forged, so NEVER trust that information.
• The useful information is in the "Received:" lines. Each of these lines represents a hop between two mail servers on the path from the sender to the recipient. These can also be forged, but there is a catch: A malicious mail server can forge the current headers, and at the end will have to send the mail to legitimate mail servers. The legitimate mail servers WILL RECORD the IP address of the sending e-mail server, and this information will ALWAYS BE TRUE.
• So, the malicious sender has no control over the Received lines of the header.
• The "Received:" lines are stacked on top of each other, so the first hop will be the lowest, and the last hop will be the first in the header. Therefore, to properly follow the path, read the lines bottom up.
• So, reading our e-mail header, this e-mail was sent from an ADSL IP address registered to an ISP in Warszawa - Poland, and then had 2 more hops in the protection systems of the delivery ISP. Visually, this was the path of the mail:

User hit "Send":

From: 65.55.90.9

NetRange:       65.52.0.0 - 65.55.255.255
CIDR:           65.52.0.0/14
NetName:        MICROSOFT-1BLK
NetHandle:      NET-65-52-0-0-1
Parent:         NET65 (NET-65-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       
Organization:   Microsoft Corporation (MSFT)
RegDate:        2001-02-14
Updated:        2013-08-20
Ref:            https://whois.arin.net/rest/net/NET-65-52-0-0-1



OrgName:        Microsoft Corporation
OrgId:          MSFT
Address:        One Microsoft Way
City:           Redmond
StateProv:      WA
PostalCode:     98052
Country:        US
RegDate:        1998-07-10
Updated:        2016-06-30

Received by: SNT004-OMC1S4.hotmail.com IP: 65.55.90.15

NetRange:       65.52.0.0 - 65.55.255.255
CIDR:           65.52.0.0/14
NetName:        MICROSOFT-1BLK
NetHandle:      NET-65-52-0-0-1
Parent:         NET65 (NET-65-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       
Organization:   Microsoft Corporation (MSFT)
RegDate:        2001-02-14
Updated:        2013-08-20
Ref:            https://whois.arin.net/rest/net/NET-65-52-0-0-1



OrgName:        Microsoft Corporation
OrgId:          MSFT
Address:        One Microsoft Way
City:           Redmond
StateProv:      WA
PostalCode:     98052
Country:        US
RegDate:        1998-07-10
Updated:        2016-06-30

-------------------------------

Then sent from the server above to: BL2FFO11FD014.mail.protection.outlook.com (10.173.160.222)

NetRange:       10.0.0.0 - 10.255.255.255
CIDR:           10.0.0.0/8
NetName:        PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle:      NET-10-0-0-0-1
Parent:          ()
NetType:        IANA Special Use
OriginAS:       
Organization:   Internet Assigned Numbers Authority (IANA)
RegDate:        
Updated:        2013-08-30
Comment:        These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices.  They are only intended for use within a private context  and traffic that needs to cross the Internet will need to use a different, unique address.
Comment:        
Comment:        These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry.  The traffic from these addresses does not come from ICANN or IANA.  We are not the source of activity you may see on logs or in e-mail records.  Please refer to http://www.iana.org/abuse/answers
Comment:        
Comment:        These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at:
Comment:        http://datatracker.ietf.org/doc/rfc1918
Ref:            https://whois.arin.net/rest/net/NET-10-0-0-0-1


OrgName:        Internet Assigned Numbers Authority
OrgId:          IANA
Address:        12025 Waterfront Drive
Address:        Suite 300
City:           Los Angeles
StateProv:      CA
PostalCode:     90292
Country:        US
RegDate:        
Updated:        2012-08-31
Ref:            https://whois.arin.net/rest/org/IANA

-----------------------------

Then sent from the server above to: BLUPR07CA082.outlook.office365.com (2a01:111:e400:8ae::37)

inet6num:       2a01:110::/31
netname:        UK-MICROSOFT-20060601
country:        GB
org:            ORG-MA42-RIPE
admin-c:        DH5439-RIPE
tech-c:         MRPA3-RIPE
status:         ALLOCATED-BY-RIR
mnt-by:         RIPE-NCC-HM-MNT
mnt-by:         MICROSOFT-MAINT
mnt-lower:      MICROSOFT-MAINT
mnt-routes:     MICROSOFT-MAINT
created:        2006-06-01T08:53:35Z
last-modified:  2016-07-12T17:06:10Z
source:         RIPE

organisation:   ORG-MA42-RIPE
org-name:       Microsoft Limited
org-type:       LIR

-----------------------------------

Then sent from the server above to: BLUPR07MB529.namprd07.prod.outlook.com (10.141.204.141)

NetRange:       10.0.0.0 - 10.255.255.255
CIDR:           10.0.0.0/8
NetName:        PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle:      NET-10-0-0-0-1
Parent:          ()
NetType:        IANA Special Use
OriginAS:       
Organization:   Internet Assigned Numbers Authority (IANA)
RegDate:        
Updated:        2013-08-30
Comment:        These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices.  They are only intended for use within a private context  and traffic that needs to cross the Internet will need to use a different, unique address.
Comment:        
Comment:        These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry.  The traffic from these addresses does not come from ICANN or IANA.  We are not the source of activity you may see on logs or in e-mail records.  Please refer to http://www.iana.org/abuse/answers
Comment:        
Comment:        These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at:
Comment:        http://datatracker.ietf.org/doc/rfc1918
Ref:            https://whois.arin.net/rest/net/NET-10-0-0-0-1

--------------------

Received: from na01-bn1-obe.outbound.protection.outlook.com (141.161.191.14)

NetRange:       141.161.0.0 - 141.161.255.255
CIDR:           141.161.0.0/16
NetName:        GEORGETOWN-NET
NetHandle:      NET-141-161-0-0-1
Parent:         RIPE-ERX-141 (NET-141-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       
Organization:   Georgetown University (GEORGE-8)
RegDate:        1990-07-31
Updated:        2008-07-01
Ref:            https://whois.arin.net/rest/net/NET-141-161-0-0-1


OrgName:        Georgetown University
OrgId:          GEORGE-8
Address:        37th and O Streets, NW
City:           Washington
StateProv:      DC
PostalCode:     20057
Country:        US
RegDate:        1990-07-31
Updated:        2010-06-08
Ref:            https://whois.arin.net/rest/org/GEORGE-8

------------------- 

Then to: LAW-CAS2.law.georgetown.edu (141.161.191.21)

NetRange:       141.161.0.0 - 141.161.255.255
CIDR:           141.161.0.0/16
NetName:        GEORGETOWN-NET
NetHandle:      NET-141-161-0-0-1
Parent:         RIPE-ERX-141 (NET-141-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       
Organization:   Georgetown University (GEORGE-8)
RegDate:        1990-07-31
Updated:        2008-07-01
Ref:            https://whois.arin.net/rest/net/NET-141-161-0-0-1


OrgName:        Georgetown University
OrgId:          GEORGE-8
Address:        37th and O Streets, NW
City:           Washington
StateProv:      DC
PostalCode:     20057
Country:        US
RegDate:        1990-07-31
Updated:        2010-06-08
Ref:            https://whois.arin.net/rest/org/GEORGE-8

---------------------

Another gap where names don't seem to match

Then to: mail.law.georgetown.edu (141.161.191.75)

NetRange:       141.161.0.0 - 141.161.255.255
CIDR:           141.161.0.0/16
NetName:        GEORGETOWN-NET
NetHandle:      NET-141-161-0-0-1
Parent:         RIPE-ERX-141 (NET-141-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       
Organization:   Georgetown University (GEORGE-8)
RegDate:        1990-07-31
Updated:        2008-07-01
Ref:            https://whois.arin.net/rest/net/NET-141-161-0-0-1


OrgName:        Georgetown University
OrgId:          GEORGE-8
Address:        37th and O Streets, NW
City:           Washington
StateProv:      DC
PostalCode:     20057
Country:        US
RegDate:        1990-07-31
Updated:        2010-06-08

By: BN1BFFO11FD048.mail.protection.outlook.com (10.58.145.3)

NetRange:       10.0.0.0 - 10.255.255.255
CIDR:           10.0.0.0/8
NetName:        PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle:      NET-10-0-0-0-1
Parent:          ()
NetType:        IANA Special Use
OriginAS:       
Organization:   Internet Assigned Numbers Authority (IANA)
RegDate:        
Updated:        2013-08-30
Comment:        These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices.  They are only intended for use within a private context  and traffic that needs to cross the Internet will need to use a different, unique address.
Comment:        
Comment:        These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry.  The traffic from these addresses does not come from ICANN or IANA.  We are not the source of activity you may see on logs or in e-mail records.  Please refer to http://www.iana.org/abuse/answers
Comment:        
Comment:        These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at:
Comment:        http://datatracker.ietf.org/doc/rfc1918
Ref:            https://whois.arin.net/rest/net/NET-10-0-0-0-1

-----------------

Received from: BN1BFFO11FD048.protection.gbl (2a01:111:f400:7c10::1:107)

inet6num:       2a01:110::/31
netname:        UK-MICROSOFT-20060601
country:        GB
org:            ORG-MA42-RIPE
admin-c:        DH5439-RIPE
tech-c:         MRPA3-RIPE
status:         ALLOCATED-BY-RIR
mnt-by:         RIPE-NCC-HM-MNT
mnt-by:         MICROSOFT-MAINT
mnt-lower:      MICROSOFT-MAINT
mnt-routes:     MICROSOFT-MAINT
created:        2006-06-01T08:53:35Z
last-modified:  2016-07-12T17:06:10Z
source:         RIPE

organisation:   ORG-MA42-RIPE
org-name:       Microsoft Limited
org-type:       LIR
descr:          Microsoft Corporation AS8075

By: SN1PR0701CA0016.outlook.office365.com (2a01:111:e400:5173::26)

inet6num:       2a01:110::/31
netname:        UK-MICROSOFT-20060601
country:        GB
org:            ORG-MA42-RIPE
admin-c:        DH5439-RIPE
tech-c:         MRPA3-RIPE
status:         ALLOCATED-BY-RIR
mnt-by:         RIPE-NCC-HM-MNT
mnt-by:         MICROSOFT-MAINT
mnt-lower:      MICROSOFT-MAINT
mnt-routes:     MICROSOFT-MAINT
created:        2006-06-01T08:53:35Z
last-modified:  2016-07-12T17:06:10Z
source:         RIPE

organisation:   ORG-MA42-RIPE
org-name:       Microsoft Limited
org-type:       LIR
descr:          Microsoft Corporation AS8075

---------------

Received from: SN1PR0701CA0016.namprd07.prod.outlook.com (10.162.96.26)

NetRange:       10.0.0.0 - 10.255.255.255
CIDR:           10.0.0.0/8
NetName:        PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle:      NET-10-0-0-0-1
Parent:          ()
NetType:        IANA Special Use
OriginAS:       
Organization:   Internet Assigned Numbers Authority (IANA)
RegDate:        
Updated:        2013-08-30
Comment:        These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices.  They are only intended for use within a private context  and traffic that needs to cross the Internet will need to use a different, unique address.
Comment:        
Comment:        These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry.  The traffic from these addresses does not come from ICANN or IANA.  We are not the source of activity you may see on logs or in e-mail records.  Please refer to http://www.iana.org/abuse/answers
Comment:        
Comment:        These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at:
Comment:        http://datatracker.ietf.org/doc/rfc1918
Ref:            https://whois.arin.net/rest/net/NET-10-0-0-0-1

By: BLUPR07MB529.namprd07.prod.outlook.com (10.141.204.141)

NetRange:       10.0.0.0 - 10.255.255.255
CIDR:           10.0.0.0/8
NetName:        PRIVATE-ADDRESS-ABLK-RFC1918-IANA-RESERVED
NetHandle:      NET-10-0-0-0-1
Parent:          ()
NetType:        IANA Special Use
OriginAS:       
Organization:   Internet Assigned Numbers Authority (IANA)
RegDate:        
Updated:        2013-08-30
Comment:        These addresses are in use by many millions of independently operated networks, which might be as small as a single computer connected to a home gateway, and are automatically configured in hundreds of millions of devices.  They are only intended for use within a private context  and traffic that needs to cross the Internet will need to use a different, unique address.
Comment:        
Comment:        These addresses can be used by anyone without any need to coordinate with IANA or an Internet registry.  The traffic from these addresses does not come from ICANN or IANA.  We are not the source of activity you may see on logs or in e-mail records.  Please refer to http://www.iana.org/abuse/answers
Comment:        
Comment:        These addresses were assigned by the IETF, the organization that develops Internet protocols, in the Best Current Practice document, RFC 1918 which can be found at:
Comment:        http://datatracker.ietf.org/doc/rfc1918
Ref:            https://whois.arin.net/rest/net/NET-10-0-0-0-1

--------------

Received from: na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0054.outbound.protection.outlook.com. [157.56.111.54])

NetRange:       157.54.0.0 - 157.60.255.255
CIDR:           157.56.0.0/14, 157.60.0.0/16, 157.54.0.0/15
NetName:        MSFT-GFS
NetHandle:      NET-157-54-0-0-1
Parent:         NET157 (NET-157-0-0-0-0)
NetType:        Direct Assignment
OriginAS:       AS8075
Organization:   Microsoft Corporation (MSFT)
RegDate:        1994-04-28
Updated:        2013-08-20
Ref:            https://whois.arin.net/rest/net/NET-157-54-0-0-1



OrgName:        Microsoft Corporation
OrgId:          MSFT
Address:        One Microsoft Way
City:           Redmond
StateProv:      WA
PostalCode:     98052
Country:        US
RegDate:        1998-07-10
Updated:        2016-06-30

By: mx.google.com with ESMTPS id c196si28806261qkb.1.2015.11.16.21.41.03

If the email failed email fail Domain-based Message Authentication, Reporting and Conformance (DMARC), why did it get delivered?

This one turns out to be pretty easy to answer. See this:

Authentication-Results

mx.google.com; spf=pass (google.com: domain of podesta@law.georgetown.edu designates 157.56.111.54 as permitted sender) smtp.mailfrom=podesta@law.georgetown.edu; dmarc=fail (p=NONE dis=NONE) header.from=outlook.com

That means that on the server there is no policy ("p") set telling the server what to do if the message fails DMARC testing...

According to DMARC's website

Does DMARC “p=none” affect the way my emails get delivered?

No. A “p=none” policy means that the Domain Owner is not asking the Receiver to take action if a DMARC check fails. This policy allows the domain owner to receive reports about messages using their domain even if they haven’t deployed SPF/DKIM, so that they could for example determine if their domain is being abused by phishers. There would be no change in how their messages are treated; however they would now have some visibility into what mail is being sent under the domain’s name. If you have not yet deployed SPF or DKIM, we do not recommend implementing them at the same time as DMARC. Change only one parameter at a time and start by DMARC first because of its reporting capabilities.

If you have deployed SPF and/or DKIM, this policy allows you to monitor your progress in deploying these protections to all of your message streams. Monitoring the domain while implementing authentication measures lets you assess the potential impact before moving to a policy that requests more aggressive protective actions by receivers, such as “p=quarantine” or “p=reject”.

Please note that receivers may have any number of filtering measures in use besides DMARC. These mechanisms, many of which have been in use for a decade or more, may include message content scanning, reputation associated with sending IP addresses, and even checking SPF and DKIM results. So even if a domain owner publishes a “p=none” policy, a receiver may still take action on a message they deem to be suspicious, or that fails an SPF or DKIM check, based on these other mechanisms. However with DMARC the domain owner will now receive statistics on such messages and be able to tell which IP address they came from, and whether they passed or failed SPF or DKIM, and can take corrective action accordingly.

In other words, the people managing this server told it, if an email fails DMARC testing, don't do anything.

Conclusion: The message was delivered because the server was configured to allow it to be delivered, even though it failed DMARC testing.

Why did this email fail Domain-based Message Authentication, Reporting and Conformance (DMARC)?

When you send an email, machines are looking at it, and reporting back information. When culling through data it's often to just search for the word "fail"... which is what I did on the header information from the Wikileaks-Podesta-probablynotScalia email.

In the authentication-Results section you can see "dmarc=fail". Why did that happen?

Authentication-Results

mx.google.com; spf=pass (google.com: domain of podesta@law.georgetown.edu designates 157.56.111.54 as permitted sender) smtp.mailfrom=podesta@law.georgetown.edu; dmarc=fail (p=NONE dis=NONE) header.from=outlook.com

Up until today I didn't know DMARC existed, but here's a page that explains it:

https://blog.returnpath.com/how-to-explain-dmarc-in-plain-english/

And here's the actual site for the organization that governs DMARC, which, if I'm lucky, I'll get to study when I feel better (not feeling good today - head cold, but better than this weekend):

https://dmarc.org/

First off, what is DMARC? According to our link,

"DMARC ensures that legitimate email is properly authenticating against established DKIM and SPF standards, and that fraudulent activity appearing to come from domains under the organization’s control (active sending domains, non-sending domains, and defensively registered domains) is blocked. Two key values of DMARC are domain alignment and reporting."

And how does it work?

"DMARC’s alignment feature prevents spoofing of the “header from” address by:

1. Matching the “header from” domain name with the “envelope from” domain name used during an SPF check, and
2. Matching the “header from” domain name with the “d= domain name” in the DKIM signature."

Well, that's good. Even I know what spoofing is - it's when somebody sends an email in the name of somebody else. I'm glad somebody's checking emails to see if that happens!

So why would an email fail DMARC?

Back to our link:

"To pass DMARC, a message must pass SPF authentication and SPF alignment and/or DKIM authentication and DKIM alignment. A message will fail DMARC if the message fails both (1) SPF or SPF alignment and (2) DKIM or DKIM alignment."

Man, don't you love tech talk? That's, like, the easiest thing in the world to understand, right?

Instead of getting bogged down, let me just show you a couple things. 

1) Our message appears to have passed SPF testing at at least one of its hops:

Received-SPF

pass (google.com: domain of podesta@law.georgetown.edu designates 157.56.111.54 as permitted sender) client-ip=157.56.111.54;

and you can see spf=pass in the Authentication rhttps://db-ip.com/141.161.191.75esults above

but then it fails at another hop:

Authentication-Results: spf=fail (sender IP is 141.161.191.75)

Why did it fail?

Received-SPF: Fail (protection.outlook.com: domain of law.georgetown.edu does

 not designate 141.161.191.75 as permitted sender)

It appears that some sort of security device had blacklisted the 141.161.191.75 IP - hence it's not a "permitted sender".

So where is that server (141.161.191.75)?

According to https://db-ip.com/all/141.161.191 that IP belongs to Ch2m Hill

and where does that specific IP live? Washington, D.C.

https://db-ip.com/141.161.191.75

Looking at Google Earth, the coordinates put you in the middle of a park that's surrounded by hotels and embassies Google Earth for that IP address:

Tired yet? Buckle up, because that only gets us halfway to failing the DMARC test. In order to fail DMARC, something had to be wrong with DKIM as well. So what was the problem with DKIM? Actually, what the heck is DKIM? 

According to DKIM.org

"DomainKeys Identified Mail (DKIM) lets an organization take responsibility for a message that is in transit.  The organization is a handler of the message, either as its originator or as an intermediary. Their reputation is the basis for evaluating whether to trust the message for further handling, such as delivery. Technically DKIM provides a method for validating a domain name identity that is associated with a message through cryptographic authentication."

Riiiiigth. Translation? It's like a secret handshake. If you don't know it, you fail. And that's what appears to have happened with this particular email. Somebody asked for the secret handshake, and the email didn't know it - bummer. 

In the header information DKIM shows up twice, and in both cases it says:

dkim=none (message not signed)

So apparently no organization was willing to take responsibility for this message in transit, either as its originator or as an intermediary. Does this mean that the From: field was spoofed? Answer:

I don't know, and neither do you (unless you're an expert in this stuff, which if you are, please feel free to correct the record)

What's important at the moment is that the data is there waiting to be interpreted by an expert, so I'm pretty sure the answer to this question is knowable.

I'll keep researching and update this post if I learn more.

Conclusion: This email failed DMARC testing. In order to fail that test there had to be an issue with

1) SPF, which there was. Looks like the domain of law.georgetown.edu didn't like the IP of 141.161.191.75... 

(On a side note, this error shows up over and over in the Wikileaks emails, so this isn't unique to this email. Just Google "domain of law.georgetown.edu does not designate 141.161.191.75 as permitted sender" to see what I mean... there's tons of emails that say the same thing.)

AND

2) DKIM, which there was, due to the message not being signed

See how easy that was? :)

 

Where did the email come from?

Emails are like snails - they leave a trail. This email is no different than any other email ever sent. The focus of this post is:

Question: Where did this email originate from?

Let's focus on this:

What are we looking at? This is a visualization of the data contained in the header of the Wikileaks Podesta email... All those strange looking names... are server names... you can Google them and find out where they live. So let's do that and see what we find:

The email in question originated from SNT150-W75 65.55.90.9 - (the IP isn't in the graphic, but is in the data itself). Using http://www.iplocationtools.com/65.55.90.9.html we find that this is a Microsoft server located in San Antonio, TX:

Un-expert, Lightly Researched Conclusion: This email's first stop after the "Send" button was clicked (by a yet to be determined sender) was a Microsoft server in San Antonio, TX.