From f092e60dfb2e2c473b63ebb163f20936678410c8 Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Tue, 18 Aug 2026 12:00:00 +0000 Subject: [PATCH] =?UTF-8?q?docs(issues):=20#0102=20=E2=80=94=20DMARC=20of?= =?UTF-8?q?=20the=20platform=20zone=20is=20p=3Dnone=20and=20belongs=20to?= =?UTF-8?q?=20IONOS?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Decision sorb: the mail hardening carried over from the mrtc diagnosis becomes an issue. Writing it up corrected the premise the AAR and dns-soll.md carried: #0006 hardened axion1337.DE, the zone with the real mailboxes, and it stands at p=reject. The platform zone .chat was never its subject and still resolves its _dmarc as a CNAME into IONOS' shared p=none - so the policy for our own domain is set by IONOS, and RFC 7489 passes that none down to all seven service names. Two senders are documented rather than assumed: Authentik as gamemaster@ via IONOS SMTP (DKIM-covered), and maintenance-notify as wartung@ over an msmtp config whose provider the template leaves open. That second path is why the issue puts "clarify the senders" ahead of any policy change - p=reject before that question is answered breaks maintenance mail silently. Co-Authored-By: Claude Opus 5 --- STATUS.md | 5 +- docs/aar/2026-08-16-mrtc-dns-record.md | 8 +- ...d-mail-haertung-der-zone-axion1337-chat.md | 99 +++++++++++++++++++ 3 files changed, 107 insertions(+), 5 deletions(-) create mode 100644 docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md diff --git a/STATUS.md b/STATUS.md index 3edc84e..e227025 100644 --- a/STATUS.md +++ b/STATUS.md @@ -2,9 +2,9 @@ -## Issues (67 open, 28 closed) +## Issues (68 open, 28 closed) -Verteilung: M1 16 · M2 20 · M3 4 · M4 12 · M5 15 +Verteilung: M1 17 · M2 20 · M3 4 · M4 12 · M5 15 | Issue | Status | Meilenstein | Priorität | Title | |---|---|---|---|---| @@ -75,6 +75,7 @@ Verteilung: M1 16 · M2 20 · M3 4 · M4 12 · M5 15 | [0099](docs/issues/0099-threadnet-web-12-upstream-sicherheitsfixes-lassen-sich-nicht-m.md) | open | M1 | medium | Upstream-Sicherheitsfixes lassen sich nicht mergen — kein gemeinsamer Vorfahre | | [0100](docs/issues/0100-threadnet-web-13-asset-pfade-tragen-weiterhin-element-themes-e.md) | open | M4 | low | Asset-Pfade tragen weiterhin "element" (themes/element/…) | | [0101](docs/issues/0101-threadnet-call-4-kaputtes-paket-0-19-2-threadnet-6-in-der-regi.md) | open | M4 | low | Kaputtes Paket 0.19.2-threadnet.6 in der Registry — Herkunft ungeklärt | +| [0102](docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md) | open | M1 | medium | DMARC der Plattform-Zone `axion1337.chat` steht auf p=none — und gehört IONOS, nicht uns | ## Active design docs (0) diff --git a/docs/aar/2026-08-16-mrtc-dns-record.md b/docs/aar/2026-08-16-mrtc-dns-record.md index 65b06e5..36be84a 100644 --- a/docs/aar/2026-08-16-mrtc-dns-record.md +++ b/docs/aar/2026-08-16-mrtc-dns-record.md @@ -57,6 +57,8 @@ erst am 16.08. — fünf Tage unbemerkt, weil niemand telefonierte. ## 5. Offen -- DMARC-/Mail-Härtung der Service-Namen (`sp=` am Apex, Null-MX + `-all` je Service-Name): - bei der Diagnose als Nebenbefund erhoben, **Entscheidung sorb steht aus** — #0006 (Apex- - DMARC) ist geschlossen und deckt die Subdomain-Frage nicht ab. +- DMARC-/Mail-Härtung der Zone `axion1337.chat`: bei der Diagnose als Nebenbefund erhoben, + seit 2026-08-18 als [#0102](../issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md) + geführt. Beim Anlegen präzisiert: #0006 hat `axion1337.**de**` gehärtet (dort heute + `p=reject`); die Plattform-Zone `.chat` hängt weiterhin als CNAME an IONOS' geteiltem + `p=none` — sie war nie Gegenstand von #0006. diff --git a/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md b/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md new file mode 100644 index 0000000..a930e26 --- /dev/null +++ b/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md @@ -0,0 +1,99 @@ +--- +type: issue +id: "0102" +status: open +created: 2026-08-18 +milestone: M1 +priority: medium +area: security +related: + - "docs/issues/0006-zone-02-apex-dmarc-ist-p-none-und-schuetzt.md" + - "docs/aar/2026-08-16-mrtc-dns-record.md" +--- +# DMARC der Plattform-Zone `axion1337.chat` steht auf p=none — und gehört IONOS, nicht uns + +> Nebenbefund der `mrtc`-Diagnose vom 2026-08-16 (siehe AAR); von sorb am +> 2026-08-18 zum Issue erhoben. + +## Befund + +**#0006 hat die falsche Zone gehärtet — nicht aus Fehler, sondern weil es die +andere war.** Dort ging es um `axion1337.de` (die Zone mit den echten +Postfächern), und die steht heute korrekt: + +``` +_dmarc.axion1337.de TXT "v=DMARC1; p=reject;" ← eigener Record, scharf +``` + +Die **Plattform-Zone** `axion1337.chat` ist davon unberührt geblieben und steht +noch so da (gemessen 2026-08-18 gegen 1.1.1.1): + +``` +_dmarc.axion1337.chat CNAME dmarc.ionos.de. → "v=DMARC1; p=none;" +``` + +Zwei getrennte Probleme in dieser einen Zeile: + +1. **`p=none` schützt nichts.** Gefälschte Mail „von" `axion1337.chat` wird beim + Empfänger nicht abgewiesen. Das ist die Domain, unter der die Nutzer ihre + Einladungen und Konto-Mails bekommen — der Phishing-Weg zeigt also genau auf + die eigene Nutzerschaft. +2. **Der Record gehört uns gar nicht.** Es ist ein CNAME auf IONOS' geteilten + Record. Die Richtlinie unserer Domain wird damit von IONOS gesetzt und kann + sich ohne unser Zutun ändern. Ein eigener TXT-Record ist Voraussetzung für + jede Härtung. + +Ohne `sp=`-Tag gilt `p=` laut RFC 7489 auch für alle Subdomains — die sieben +Service-Namen erben also ebenfalls `none`. Und alle sieben tragen, als +IONOS-Voreinstellung, MX- und SPF-Records, obwohl unter ihnen nie Mail läuft: + +``` +matrix|account|auth|admin|wiki|turn|mrtc . axion1337.chat + MX 10 mx00/mx01.ionos.de. + TXT "v=spf1 include:_spf-eu.ionos.com ~all" ← Softfail +``` + +## Wer wirklich sendet (vor jeder Änderung zu bestätigen) + +Zwei belegte Absender, **beide am Apex**, keiner unter einem Service-Namen: + +| Absender | Adresse | Weg | Fundstelle | +|---|---|---|---| +| Authentik (Enrollment, Passwort) | `gamemaster@axion1337.chat` | `smtp.ionos.de:587` | `gitops:apps/authentik/authentik.yaml` | +| Wartungsmeldungen der Hosts | `wartung@axion1337.chat` | msmtp, Provider laut Template offen | `gitops:host-config/maintenance-notify/` | + +DKIM ist am Apex vorhanden: `s1-ionos`, `s2-ionos` und `s42582890` zeigen als +CNAME auf `*.dkim.ionos.com`. Für Authentik über IONOS-SMTP ist die Signatur +damit gedeckt. **Ungeklärt ist der Weg von `maintenance-notify`** — die +`msmtprc.template` trägt Platzhalter und verweist auf „your own +transactional-mail provider". Läuft der nicht über IONOS, bricht `p=reject` +genau diese Meldungen, und zwar still. + +## Vorschlag + +Die Reihenfolge aus #0006 gilt unverändert: **erst Absender klären, dann +Richtlinie verschärfen** — umgekehrt zerlegt es den Versand unbemerkt. + +1. **Klären**, worüber `maintenance-notify` tatsächlich versendet, und ob es + weitere Absender auf `@axion1337.chat` gibt (Synapse verschickt derzeit + nichts — im Zweifel gegenprüfen). +2. **Service-Namen stilllegen**, die nachweislich weder senden noch empfangen + (`matrix`, `account`, `auth`, `admin`, `wiki`, `turn`, `mrtc`): Null-MX + `MX 0 .` und `TXT "v=spf1 -all"`. Risikoarm, weil dort nie Mail lief. +3. **Eigenen `_dmarc`-Record** für `axion1337.chat` anlegen (CNAME ersetzen), + zunächst `p=quarantine; rua=…`, Reports beobachten, dann `p=reject`. +4. **Apex-SPF bleibt `~all`.** Dieselbe Abwägung wie in #0006: neben scharfem + DMARC ist der Gewinn von `-all` gering, das Risiko eines vergessenen + legitimen Absenders real. + +## Abnahme + +- `_dmarc.axion1337.chat` ist ein **eigener** TXT-Record, nicht mehr der + IONOS-CNAME, und trägt mindestens `p=quarantine`. +- Die sieben Service-Namen liefern `MX 0 .` und `v=spf1 -all`. +- Eine Testmail von Authentik (Passwort-Zurücksetzen) und eine + Wartungsmeldung kommen nachweislich weiterhin an — **verifiziert, nicht + angenommen**. +- `notfallhandbuch:dns-soll.md` und `pruefe-dns.sh` tragen den neuen Soll-Stand; + der bisherige Satz „Härtung vorgeschlagen, aber nicht entschieden" wird + ersetzt.