docs(issues): #0102 — DMARC of the platform zone is p=none and belongs to IONOS

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 <noreply@anthropic.com>

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.

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.