{
 "schemaVersion": 1,
 "registerId": "mde-anchor-verification-v1",
 "dateModified": "2026-08-08",
 "policy": {
  "sourceIsSealed": true,
  "statement": "The .eml source files are not published and are not downloadable. They contain private discussion unrelated to the research record. What is published is everything needed to verify the anchor: the cryptographic signature parameters, the receiving server's own verdict, the message identifiers, the timestamps, and the SHA-256 of every attachment. The sealed source is provided to serious verifiers on request.",
  "whyThisIsStrongerNotWeaker": "A published mailbox file proves nothing on its own, because a file can be edited. What proves the anchor is the DKIM signature: a cryptographic assertion made by the sending domain and verified by the receiving server at the time of transit, which cannot be reproduced after the fact without the private key. Publishing the verdict and withholding the body is the ordinary practice for dated evidence, and it is what a verifier actually needs.",
  "enforcement": "\\.(eml|mbox|msg|pst|ost|olm)$ is a deny pattern in deploy/netlify-public-allowlist.json. Verified 2026-08-08: 0 .eml files in dist-netlify-public, and both anchor paths return 404 on the live site."
 },
 "howToVerify": [
  "1. Read the Received lines. They carry the receiving server's own timestamps. A sender sets the Date header; a sender cannot write these.",
  "2. Compare them with the Date header. The gap should be seconds, and larger for a larger attachment.",
  "3. Read the ARC-Seal t= value. It is a third timestamp, sealed by google.com, and it carries no expiry.",
  "4. Read the Authentication-Results header. Confirm dkim=pass and spf=pass.",
  "5. Confirm the DKIM signing domain and selector match the values published here.",
  "6. Compute SHA-256 of each attachment and compare with the published values.",
  "7. Open the message in Gmail by Message-ID search, then Show Original, for an independent copy of the same headers.",
  "8. Read the manuscript. Quoted passages are at the stated line numbers.",
  "The sealed source is provided to serious verifiers on request. It is not published."
 ],
 "anchors": [
  {
   "id": "A1",
   "label": "8 December 2024 manuscript anchor",
   "dateHeader": "Sun, 8 Dec 2024 02:45:18 +0000",
   "dateUtc": "2024-12-08T02:45:18Z",
   "messageIdPrefix": "CAGPsKAnp-DLDBOeBAh4t9XsqJBKdoe07uORGF86meoSMFnin7w",
   "dkim": {
    "present": true,
    "signingDomain": "mastermindpromotion.com",
    "selector": "google",
    "algorithm": "rsa-sha256",
    "signaturePrefix": "TuT3HP1O",
    "receivingServerVerdict": "mx.google.com; dkim=pass header.i=@mastermindpromotion.com header.s=google; spf=pass",
    "note": "dkim=pass is the receiving server's verdict, not the author's claim. It was written by Google's mail servers at the time of transit."
   },
   "attachments": 5,
   "attachmentNote": "Five manuscript text attachments. Their content is the priority record. Quoted passages carry a line number so any held copy can be checked at that line.",
   "verifiedBy": "the research record, 2026-08-08, headers read at source from the receiving-side copy",
   "importantCaveat": "The copy previously held at evidence/dec8-2024-manuscript.eml is a SENT-FOLDER EXPORT: zero DKIM-Signature, zero Authentication-Results, zero Received hops. It cannot support the verification claim. The receiving-side copy is the evidentiary artefact and it is the one held for verifiers.",
   "sha256OfReceivedCopy": "ecdc8999e5326235",
   "receivedCopyBytes": 2167675,
   "artefactLocation": "evidence/received-dkim/ , git-tracked, denied at the publish boundary by the .eml pattern"
  },
  {
   "id": "A2",
   "label": "30 April 2025 manuscript anchor",
   "dateHeader": "Wed, 30 Apr 2025 13:37:05 +0100",
   "dateUtc": "2025-04-30T12:37:05Z",
   "dkim": {
    "present": true,
    "signingDomain": "mastermindpromotion.com",
    "selector": "google",
    "algorithm": "rsa-sha256",
    "signaturePrefix": "NQJw/onm",
    "receivingServerVerdict": "mx.google.com; dkim=pass header.i=@mastermindpromotion.com header.s=google; spf=pass"
   },
   "attachments": 2,
   "attachmentNote": "One PDF manuscript and one signature image. Quoted passages carry a page number.",
   "verifiedBy": "the research record, 2026-08-08, headers read at source from the receiving-side copy",
   "datingNote": "The header settles a question that had two answers in circulation. It reads 2025, not 2026. The filename and the homepage already said 2025; one message said 2026. The artefact decides.",
   "sha256OfReceivedCopy": "d52730f3b8246dff",
   "receivedCopyBytes": 33275268,
   "artefactLocation": "evidence/received-dkim/ , git-tracked, denied at the publish boundary by the .eml pattern"
  }
 ],
 "wordingRules": {
  "mustNotSay": [
   "the .eml file is downloadable",
   "download the .eml",
   "the full email is published"
  ],
  "mustSay": "The sealed source is provided to serious verifiers on request. The signature parameters, the receiving server's verdict and the attachment hashes are published.",
  "why": "A claim that a file is downloadable is checked in one click, and a reader who finds a 404 stops believing the rest of the page. The site already carries a correction rule replacing the older downloadable wording, and this register is its source of truth."
 },
 "theStrongestFact": {
  "headline": "Three independent server-written timestamps per anchor, none of them settable by the sender.",
  "whyItBeatsDKIM": "DKIM is the right proof and it is hard for a non-technical reader to follow. The Received line is not. A sender can set a Date header to anything. A sender cannot write a receiving server's Received line, and cannot write the timestamp Google seals into its own ARC-Seal. Anyone can understand that in one sentence, and it is exactly as hard to fake.",
  "creditedTo": "the research record found the Received line and recognised that it outranks the DKIM for a general reader. the research record verified it at source and found the third timestamp inside the ARC-Seal.",
  "anchors": {
   "A1": {
    "senderDateHeader": "2024-12-08T02:45:18Z",
    "serverWritten": [
     {
      "source": "Received hop 1",
      "utc": "2024-12-08T02:45:30Z",
      "secondsAfterSenderDate": 12
     },
     {
      "source": "ARC-Seal t=1733625931, sealed by d=google.com",
      "utc": "2024-12-08T02:45:31Z",
      "secondsAfterSenderDate": 13
     },
     {
      "source": "Received hop 2",
      "utc": "2024-12-08T02:45:33Z",
      "secondsAfterSenderDate": 15
     }
    ],
    "plainEnglish": "The author set the Date at 02:45:18. Google's servers recorded receiving it 12, 13 and 15 seconds later. Those three records were written by Google, not by the author."
   },
   "A2": {
    "senderDateHeader": "2025-04-30T12:37:05Z",
    "serverWritten": [
     {
      "source": "Received hop 1",
      "utc": "2025-04-30T12:37:29Z",
      "secondsAfterSenderDate": 24
     },
     {
      "source": "ARC-Seal t=1746016650, sealed by d=google.com",
      "utc": "2025-04-30T12:37:30Z",
      "secondsAfterSenderDate": 25
     },
     {
      "source": "Received hop 2",
      "utc": "2025-04-30T12:37:33Z",
      "secondsAfterSenderDate": 28
     }
    ],
    "plainEnglish": "Date set at 12:37:05. Google recorded receiving it 24, 25 and 28 seconds later. A 33MB attachment takes longer to transit than a 2MB one, which is why this interval is wider than the December one and is itself consistent."
   }
  }
 },
 "durability": {
  "finding": "The sender-domain DKIM signature carries an x= expiry. The ARC-Seal carries none.",
  "verifiedAtSource": "the research record, 2026-08-08, both anchors: DKIM-Signature has x=, ARC-Seal (i=1, a=rsa-sha256, d=google.com, s=arc-20240605) has no x=.",
  "consequence": "ARC is the durable verification route and DKIM is corroboration, not the other way round. Copy that leads with DKIM alone is leading with the perishable half.",
  "note": "This confirms an existing position in lane canon rather than discovering a new one."
 },
 "provenanceProof": {
  "method": "byte arithmetic, no inference required",
  "explanation": "The received copy and the sent copy of the same message differ only by the transit header block. Message-ID and Date are identical in both, so the difference is the DKIM, ARC and Received headers and nothing else.",
  "A1": {
   "receivedBytes": 2167675,
   "sentBytes": 2157222,
   "difference": 10453
  },
  "A2": {
   "receivedBytes": 33275268,
   "sentBytes": 33264662,
   "difference": 10606
  },
  "conclusion": "Same message, with and without transit headers. Nothing about the relationship between the two copies has to be assumed."
 }
}