sorb/management
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f092e60dfb2e2c473b63ebb163f20936678410c8
management/docs/issues/0102-dmarc-und-mail-haertung-der-zone-axion1337-chat.md
T
Thore CimbalandClaude Opus 5 f092e60dfb 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>
2026-08-18 12:00:00 +00:00

4.1 KiB
Raw Blame History

type, id, status, created, milestone, priority, area, related
type id status created milestone priority area related
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

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.
Reference in New Issue View Git Blame Copy Permalink