sorb/management
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
6731d2a70f1af716d9e199b307dab93fc6fe9e2c
management/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md
T
Thore CimbalandClaude Opus 5 a90ebd379b docs(issues): wiki enrolment live, mail blocker gone, console seen for the wrong host 
Three corrections to questions I should not have asked again.

#0103 is implemented: autoEnrollGroups points at wiki-anwender, verified in the live
database rather than from the job log. The decision was already in #0049 - the role
model was built, only the way in was missing.

#0102's blocker was in the documentation all along: maintenance-notify sends under
.de, not .chat, via IONOS on 587. The MAIL_FROM in config.example is an example, not
the operating state. So hardening .chat cannot break maintenance mail, and Authentik
remains its only .chat sender - DKIM-covered.

#0008 is not resolved by the console screenshots: they show fw-matrix-cx42, the
Matrix host, while the issue asks which rule keeps 9090 and 3100 shut on CFGMON.
Still open. What they did show is worth keeping: SSH and the Kubernetes API are
properly source-restricted, and several rules open ports to everyone where nothing
listens - including an inbound smtp 587 that cannot help the outbound sending it was
presumably added for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-19 12:00:00 +00:00

5.5 KiB
Raw Blame History

type, id, status, created, milestone, priority, area, related, gitlab_iid
type id status created milestone priority area related gitlab_iid
issue 0102 open 2026-08-18 M1 medium security
docs/issues/0006-zone-02-apex-dmarc-ist-p-none-und-schuetzt.md
docs/aar/2026-08-16-mrtc-dns-record.md
40

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.

Blocker aufgelöst 2026-08-19 — maintenance-notify sendet unter .de

Die offene Frage („worüber verschickt maintenance-notify tatsächlich?") steht in der Doku, nicht auf dem Host: gitops:docs/deployment-guides/07-host-maintenance-notifications.md, Abschnitt Stolpersteine.

Absender-Domain ≠ Matrix-Server-Domain. […] bei axion1337 z.B. Mail unter .de, Matrix unter .chat — MAIL_FROM und der user/from in msmtprc müssen zur tatsächlichen Mail-Domain passen.

Der Versand läuft über IONOS auf 587/STARTTLS (465 ist ausgehend blockiert, ebenfalls dort dokumentiert). Die MAIL_FROM="wartung@axion1337.chat" in config.example ist ein Beispiel, nicht der Betriebsstand.

Folge für dieses Issue: Eine Härtung von axion1337.chat berührt maintenance-notify nicht — dessen Absenderdomain .de trägt bereits p=reject (#0006). Damit bleibt als einziger .chat-Absender Authentik (gamemaster@, IONOS-SMTP, DKIM über die drei *.dkim.ionos.com-CNAMEs gedeckt).

Der Vorschlag im Issue ist damit ohne die befürchtete Nebenwirkung umsetzbar: eigener _dmarc-TXT statt IONOS-CNAME, zunächst p=quarantine mit rua=, danach p=reject; Null-MX und -all auf den sieben Service-Namen. Abnahme unverändert: Authentik-Testmail und eine Wartungsmeldung müssen nachweislich ankommen.

Reference in New Issue View Git Blame Copy Permalink