Merge branch 'main' of https://github.com/robertdavidgraham/hunter-dkim into main

README.md

@@ -59,7 +59,7 @@ Many can't be validated. They are sent from domains that don't use DKIM
 to sign outgoing emails. Others used DKIM when sent, but we can no longer
 find the public-keys that would authenticate them (it's been years).
 
-### "Can't signatures can be faked, replayed, forged, or cheated?"
+### "Can't signatures be faked, replayed, forged, or cheated?"
 
 Not cryptographic signatures, at least, not in any practical/reasonable manner.
 
@@ -90,7 +90,7 @@ The signature covers both the metadata and the body. Yes, some email metadata is
 the signature, esoteric things like `X-Received:` headers. But the signature does cover the
 ones we care about: `Date:`, `From:`, `To:`, and `Subject:`.
 
-### "OKay, the email and metaday, but what about the envelope?"
+### "OKay, the email and metadata, but what about the envelope?"
 
 Several people have cited this Wikipedia article that says that 
 [DKIM signatures do not encompass the message envelope](https://en.m.wikipedia.org/wiki/DomainKeys_Identified_Mail).
@@ -98,7 +98,7 @@ This is correct, but it doesn't mean what you might think it means.
 
 It's like if somebody sent you a printed copy of this email. The address
 on the outside is unrelated to the contents -- it doesn't mean the contents
-aren't authenticate.
+aren't authenticated.
 
 In any case, Google forces the two to be the same. If the email says `From:` a 
 GMail account, and it was authenticated by GMail's DKIM key, then it came from
@@ -111,11 +111,11 @@ DKIM verifies the contents of that field (that somebody didn't alter after signi
 but not that it's the correct date. Any fraudulent information can be put here.
 
 But the fraud would have to occur at the time the email was sent. And that time
-would have be before October 2016, when GMail changed their DKIM signing keys.
+would have to be before October 2016, when GMail changed their DKIM signing keys.
 
 Thus, it's effectively timestamped "some time after January 2012 and before October 2016".
 
-In other words, we know it came from Vadym Pozharskyi, but he couldn't sent it
+In other words, we know it came from Vadym Pozharskyi, but he couldn't have sent it
 around a year later than the authenticated email headers claimed he sent it, like April 2016
 instead of April 2015.
 
@@ -142,7 +142,7 @@ of the old key, including archives of old sites, log files from servers, and so
 on.
 
 Thus, in theory the system only works when the domain in question is currently
-providing the public-key to validate signatures, in practice we can know GMail's
+providing the public-key to validate signatures, but in practice we can know GMail's
 old key even if they don't provide it directly.
 
 The proper key is one of the files in this project, but of course, I could
@@ -167,7 +167,7 @@ provide the correct public-key.
 
 ### "What about this page that says DKIM can be fooled?"
 
-I lot of confident Twitter "experts" proclaim tha DKIM can be faked.
+A lot of confident Twitter "experts" proclaim that DKIM can be faked.
 They are just repeating rumors without understanding how. They also
 aren't reproducing this verification or demonstrating how this email
 specifically could've been faked.
@@ -222,7 +222,7 @@ conspiracy was this sophisticated, they could do better emails. This one is lame
 ### "How did you see that secret metadata, in a debugger?"
 
 In some cases, metadata in files like photographs require special tools. But emails
-are just text, even the metadata. You can open in any text editor. Just click
+are just text, even the metadata. You can open them in any text editor. Just click
 on this [link](https://raw.githubusercontent.com/robertdavidgraham/hunter-dkim/main/Meeting%20for%20coffee.eml)
 and see for yourself.
 

ots-timestamp/README.md

@@ -0,0 +1,28 @@
+# Timestamped Email
+
+This email both passes DKIM verification:
+
+```
+$ ../verify.py timestamped.eml
+timestamped.eml: DKIM signature verified
+```
+
+...and has been timestamped with [OpenTimestamps](https://opentimestamps.org),
+proving that the email itself existed prior to 2016:
+
+```
+$ sudo pip3 install opentimestamps-client
+$ ots verify timestamped.eml.ots
+Assuming target filename is 'timestamped.eml'
+Success! Bitcoin block 429347 attests existence as of 2016-09-11 EDT
+```
+
+If you don't have Bitcoin Core installed, you can also verify it manually
+against a block explorer:
+
+```
+$ ots --no-bitcoin verify timestamped.eml.ots
+Assuming target filename is 'timestamped.eml'
+Not checking Bitcoin attestation; Bitcoin disabled
+To verify manually, check that Bitcoin block 429347 has merkleroot e97422f79cddd4fbd176272b3aba09cbdae6874f5eb81db2a474b2e812076109
+```

ots-timestamp/timestamped.eml

@@ -0,0 +1,54 @@
+Return-Path: <gmaxwell@gmail.com>
+X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on petertodd.org
+X-Spam-Level: 
+X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
+	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,
+	URIBL_BLOCKED autolearn=ham version=3.3.2
+X-Original-To: pete@petertodd.org
+Delivered-To: pete@petertodd.org
+Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170])
+	by petertodd.org (Postfix) with ESMTPS id 24A9E4002F
+	for <pete@petertodd.org>; Mon, 10 Nov 2014 04:20:53 -0500 (EST)
+Authentication-Results: petertodd.org; dkim=pass
+	reason="2048-bit key; insecure key"
+	header.d=gmail.com header.i=@gmail.com header.b=LeWKVXY0;
+	dkim-adsp=pass; dkim-atps=neutral
+Received: by mail-ie0-f170.google.com with SMTP id tp5so8920171ieb.15
+        for <pete@petertodd.org>; Mon, 10 Nov 2014 01:20:07 -0800 (PST)
+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
+        d=gmail.com; s=20120113;
+        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
+         :content-type;
+        bh=CPlUQuCWYapDt94Wk/7HWjAPNPGC5mjeaQa/Y+uB89U=;
+        b=LeWKVXY0I2OkI6YJJ3gaPIJAgvhWqxO9/o+eW3vQ8TwaTnfv5a03hlnk2Fe6NLlQyw
+         eLDOVwMrDF+iFZtlnZWSAqXim6+FmHNOmfLCfdY6hTqI1cvqfdKdjzTUeU4BWomU1Kdy
+         iWQ8xkbBcgWo/c9xgU6mnkXWlThLqsYRIswqTK/UyA1YUIsFVeFfChy+d2Dg14I0AQbi
+         s4CXWfbzUPQvlGQaf8z3yDFc8ynL8CX6Z0i7HdgXz4s+AZ5y7yIjevmgnkKRshbENfHS
+         IRG5rBxkcm0hE5Wd6OuFSeIUBZt3tUb1v4iNl8WXne6Z+5uL0hPos8rIl1WGOrFg7S+L
+         NDxQ==
+MIME-Version: 1.0
+X-Received: by 10.107.11.67 with SMTP id v64mr849940ioi.76.1415611207314; Mon,
+ 10 Nov 2014 01:20:07 -0800 (PST)
+Received: by 10.107.168.211 with HTTP; Mon, 10 Nov 2014 01:20:07 -0800 (PST)
+In-Reply-To: <20141110091100.GA2501@savin.petertodd.org>
+References: <20141110091100.GA2501@savin.petertodd.org>
+Date: Mon, 10 Nov 2014 09:20:07 +0000
+Message-ID: <CAAS2fgSXktMgCBohOA787_CaZ72tx+9cL2ZDjf8p9MjdzzUTgA@mail.gmail.com>
+Subject: Re: BIP # request for CHECKLOCKTIMEVERIFY
+From: Gregory Maxwell <gmaxwell@gmail.com>
+To: Peter Todd <pete@petertodd.org>
+Content-Type: text/plain; charset=UTF-8
+Content-Length: 246
+Lines: 11
+
+BIP65 appears free to me.
+
+If I've not screwed up, take it.
+
+On Mon, Nov 10, 2014 at 9:11 AM, Peter Todd <pete@petertodd.org> wrote:
+> thanks
+>
+> --
+> 'peter'[:-1]@petertodd.org
+> 000000000000000016871bf68cc941c38ae836e6ed8853e975de4183d1ac9f6c
+