Verification

How to check this archive yourself

A fair criticism of the site as first published: the browse table shows summaries, not original messages. That is a real gap, and it is worth being precise about why it exists and how to close it.

Why the site shows summaries

The archive holds roughly 421,000 messages. Rendering them as individual pages would mean publishing an indexed, searchable copy of every private message in the corpus — including the many that concern ordinary members and people who wrote to the party, not public figures. The browse table therefore carries the assessment and a short description, and points at the underlying record.

That is a deliberate limit on this website, not on the archive. Every claim in the table can be traced back to a real file. The rest of this page shows how.

1. Get the archive

Two torrents carry identical content. Take either.

Both magnets are on the browse page. Verify the download completed — the client checks every piece against the hash in the torrent, so a finished download is byte-identical to the published copy.

2. Unpack the packed variant

# one tar per top-level directory
for f in *.tar; do tar -xf "$f"; done

# result
01_EMAIL/  02_DATABASES/  03_DOCUMENTS/  04_TABULAR_DATA/
05_CREDENTIALS_AND_KEYS/  06_MEDIA/  99_FOR_JOURNALISTS/

Nothing is compressed inside the tars — they are plain archives, so tar -tf 01_EMAIL.tar | head lists contents without extracting.

3. What an mbox file is

01_EMAIL/ contains one directory per mailbox, and inside each, one or more part-NN.mbox files.

mbox is the oldest and most widely supported mailbox format. A single file holds many complete messages, concatenated. The separator is a line beginning with the five characters From — note the space, and note there is no colon, which distinguishes it from the From: header inside each message.

From [email protected] Mon Jan  1 00:00:00 2020
Return-Path: <[email protected]>
Received: from mail.afd.de (mail.afd.de [1.2.3.4])
        by mx.example.de with ESMTPS id abc123
        for <[email protected]>; Mon, 3 Jun 2024 10:22:11 +0200
DKIM-Signature: v=1; a=rsa-sha256; d=afd.de; s=selector1;
        h=from:to:subject:date:message-id; bh=...; b=...
From: Alice Weidel <[email protected]>
To: [email protected]
Subject: Re: Landesvorstand
Date: Mon, 3 Jun 2024 10:22:03 +0200
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_Part_1"

------=_Part_1
Content-Type: text/plain; charset="utf-8"

Der Landesvorstand hat beschlossen ...

------=_Part_1
Content-Type: application/pdf; name="Protokoll.pdf"
Content-Transfer-Encoding: base64

JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGgg...
------=_Part_1--

From [email protected] Mon Jan  1 00:00:00 2020
... next message ...

Every message keeps its original RFC 822 headers and its original MIME body. Attachments are still base64 inside the message, exactly as they travelled. The archive was deduplicated by Message-ID, so a message that existed on three systems appears once.

Open it in a real mail client

# Thunderbird: point Local Folders at the directory, or
#   File > Open > Saved Message, then pick the .mbox

# mutt
mutt -f 01_EMAIL/[email protected]/part-01.mbox

# notmuch — best for searching across the whole corpus
notmuch new --root=01_EMAIL
notmuch search 'from:gauland and subject:spende'

# or just grep the bytes, mbox is plain text
rg -i 'Untreue|Veruntreuung' 01_EMAIL/

Extract one message as a standalone .eml

Mail clients can save any message as .eml. From the command line, formail (from procmail) splits an mbox into separate files:

formail -s formail -I "From " < part-01.mbox > msg.$FILENAME
# or, per message index:
csplit -z -f msg- part-01.mbox '/^From /' '{*}'

4. Verify authenticity with DKIM

This is the part that answers "how do I know it is real". Many messages carry a DKIM-Signature: a cryptographic signature made by the sending domain's mail server, covering specified headers and a hash of the body.

Check it

# 1. save the message
formail -1 < part-01.mbox > message.eml

# 2. verify with python-dkim
python3 -m pip install dkimpy
python3 -c "
import dkim
raw = open('message.eml','rb').read()
print('valid:', dkim.verify(raw))
"

# 3. or with opendkim
opendkim-testmsg < message.eml

# 4. or with mailauth (node)
npx mailauth report < message.eml

Check the signing key still exists

The signature names a selector. The public key lives in DNS at <selector>._domainkey.<domain>:

dig +short selector1._domainkey.afd.de TXT

5. Read the delivery chain

Received headers record every server that handled the message. Read them bottom-up: the lowest is the first server that saw it, the top one is the last.

Received: from mail.afd.de (mail.afd.de [1.2.3.4])
        by mx.example.de with ESMTPS id abc123
        for <[email protected]>; Mon, 3 Jun 2024 10:22:11 +0200

What to look for:

• Do the timestamps increase monotonically going up the chain?
• Does the top Received match the recipient's real mail provider?
• Is there a gap or a re-injection from an unexpected host? That suggests forwarding, not forgery — but it is worth explaining.
• Do the hostnames resolve to plausible IPs?

Authentication-Results, added by the receiving server, records the SPF, DKIM and DMARC verdicts at delivery time. That is stronger evidence than a re-check today, because it cannot have been affected by later key rotation.

6. Cross-check the content

The strongest verification is agreement between independent files:

• Same amount, different documents. An invoice in 03_DOCUMENTS/ and a payment confirmation in 01_EMAIL/ should agree on figure, date and reference number.
• Same event, different mailboxes. A meeting discussed in two mailboxes with consistent dates and attendees.
• Party records vs published accounts. Rechenschaftsbericht documents can be checked against the published party accounts.
• Third-party records. Company registers, court dockets, published minutes.

What this archive cannot prove

Being explicit about the limits is part of being trustworthy:

• It cannot prove authorship by a named individual unless the message is DKIM-signed by that person's own domain and the content matches their role.
• It cannot prove a scan or a PDF is unaltered — check pdfinfo for a ModDate later than CreationDate.
• It cannot prove completeness. The archive is partial.
• It cannot prove an allegation is true. An email alleging embezzlement is evidence that the allegation was made, not that money moved.

A defensible sentence

When citing this material, something like this does the work:

The document is an email dated 3 June 2024, sent from [email protected] to
[email protected], with a valid DKIM signature for the afd.de domain and a
Received chain consistent with delivery through the party's mail server. Its
Message-ID places it in the same thread as [other message], which corroborates
the sequence of events. The attached invoice carries metadata consistent with
the claimed date, and its reference number appears in a second, independently
obtained email.

That is verification. "We obtained documents" is not.

Tools used above

← Browse the archive  ·  How records were assessed →