Neues Forgejo-Tool validiert E-Mail-Sicherheitsprotokolle für selbst gehostete Server

Das Sig-I/O-Team bei Forgejo hat ein neues Open-Source-Dienstprogramm namens mailcheck veröffentlicht, das speziell für Systemadministratoren entwickelt wurde, die ihre eigene E-Mail-Infrastruktur verwalten. Dieses am 5. Oktober 2026 veröffentlichte Kommandozeilen-Tool ermöglicht es Betreibern, kritische E-Mail-Sicherheitsprotokolle wie SPF, DKIM, DMARC und TLSA zu validieren, ohne das Risiko, Testnachrichten zu versenden. Es bietet eine leichtgewichtige Möglichkeit, Konfigurationsfehler zu diagnostizieren, die in selbst gehosteten Umgebungen häufig zu Zustellproblemen oder Sicherheitslücken führen.

Was ist passiert

Die Veröffentlichung stellt ein spezialisiertes Diagnose-Tool vor, das DNS-Policy-Prüfungen und SMTP-Konnektivitätstests durchführt. Im Gegensatz zu umfassenden Simulatoren für die E-Mail-Authentifizierung konzentriert sich mailcheck auf die Validierung der Syntax und Existenz von DNS-Einträgen, die festlegen, wie andere Server eingehende E-Mails Ihrer Domain behandeln. Das Tool prüft Sender Policy Framework (SPF)-Einträge auf syntaktische Gültigkeit und Lookup-Limits, verifiziert die Kodierung öffentlicher Schlüssel für DomainKeys Identified Mail (DKIM) und inspiziert Richtlinien für Domain-based Message Authentication, Reporting, and Conformance (DMARC).

Für die Transportsicherheit untersucht das Tool Transport Layer Security Authentication (TLSA)-Einträge, die Teil des DNS-based Authentication of Named Entities (DANE)-Protokolls sind. Es verbindet sich mit Port 25 des Ziel-Mail-Servers, um die SMTP-Verfügbarkeit und die STARTTLS-Unterstützung zu überprüfen. Das Tool trennt die Zertifikatsüberprüfung vom TLS-Handshake, sodass es Zertifikate inspizieren kann, die nicht öffentlich vertrauenswürdig sind, aber im DANE-Kontext gültig sein können. Diese Unterscheidung ist entscheidend für Administratoren, die sich für die Authentifizierung auf DANE verlassen, anstatt auf traditionelle Zertifizierungsstellen.

Das Dienstprogramm gibt Ergebnisse unter Verwendung standardmäßiger Nagios-Exit-Codes aus, was die Integration in bestehende Monitoring-Stacks erleichtert. Ein Status von 0 bedeutet OK, 1 ist WARNING, 2 ist CRITICAL und 3 ist UNKNOWN. Der Gesamtstatus spiegelt das schwerwiegendste Ergebnis wider, das während der Prüfung gefunden wurde. Wenn beispielsweise SPF gültig ist, aber kein TLSA-Eintrag existiert, gibt das Tool einen WARNING-Status zurück, einschließlich detaillierter Metriken wie der Verbindungsdauer in Millisekunden.

Wichtige Details

• Das Tool verwendet die Bibliothek github.com/miekg/dns (v1.1.70) für DNS-Abfragen und unterstützt EDNS0- sowie DNSSEC-bezogene Funktionen.
• SPF-Prüfungen validieren die Record-Syntax und das Limit von zehn DNS-Lookups, simulieren jedoch nicht rekursiv jede mögliche Absender-IP.
• Die DKIM-Validierung erfordert die manuelle Eingabe des Selectors, da DNS keine universelle Methode bereitstellt, um alle Selector aufzulisten.
• DMARC-Prüfungen validieren Record-Tags und greifen auf den Eintrag der Organisationsdomain zurück, wenn für die spezifische Subdomain kein Eintrag vorhanden ist.
• TLSA-Matching unterstützt die Verwendungen 2 und 3 und betrachtet Records nur dann als sicher, wenn auch der MX-Lookup DNSSEC-geschützt war.
• Die minimale Standard-TLS-Version ist 1.2, wodurch Server, die nur Legacy-Versionen wie 1.0 oder 1.1 unterstützen, die Prüfung nicht bestehen.

Hintergrund

E-Mail-Sicherheit stützt sich stark auf DNS-Einträge, um Spoofing zu verhindern und eine verschlüsselte Übertragung zu gewährleisten. SPF teilt empfangenden Servern mit, welche IP-Adressen autorisiert sind, E-Mails für eine Domain zu senden. DKIM fügt E-Mails eine digitale Signatur hinzu, damit Empfänger überprüfen können, dass die Nachricht während der Übertragung nicht verändert wurde. DMARC kombiniert diese beiden Mechanismen und weist Empfänger an, was zu tun ist, wenn eine E-Mail die SPF- oder DKIM-Prüfung nicht besteht, z. B. sie abzulehnen oder als Spam zu markieren.

DANE und TLSA gehen noch weiter, indem sie TLS-Zertifikate an DNS-Einträge binden. Dies verhindert Man-in-the-Middle-Angriffe, bei denen ein Angreifer ein gültiges, aber nicht autorisiertes Zertifikat präsentieren könnte. Allerdings hängt DANE von DNSSEC (Domain Name System Security Extensions) ab, um sicherzustellen, dass die DNS-Einträge selbst nicht manipuliert wurden. Mailcheck meldet den DNSSEC-Status basierend auf dem Authenticated Data (AD)-Bit, das vom rekursiven Resolver zurückgegeben wird, was bedeutet, dass es der Validierung des Resolvers vertraut, anstatt eine vollständige eigene DNSSEC-Kettenvalidierung durchzuführen.

Warum es wichtig ist

Für Teams, die selbst gehostete Software betreiben, ist die E-Mail-Zustellbarkeit ein häufiger Schmerzpunkt. Falsch konfigurierte SPF-Einträge können dazu führen, dass legitime Benachrichtigungen im Spam-Ordner landen, während fehlende DMARC-Richtlinien Domains anfällig für Phishing-Angriffe machen. Traditionelle Testmethoden beinhalten oft das Senden tatsächlicher E-Mails an externe Dienste wie Gmail oder Outlook, was langsam, unpräzise ist und Rate-Limits oder Missbrauchsfilter auslösen kann. Mailcheck bietet eine deterministische Möglichkeit, Konfigurationen lokal zu validieren, bevor Änderungen in produktive DNS-Zonen deployed werden.

Darüber hinaus ist die Trennung der Zertifikatsüberprüfung vom TLS-Handshake für interne oder private Mail-Server von erheblicher Bedeutung. Administratoren verwenden häufig selbst signierte oder private CA-Zertifikate für die interne Kommunikation. Standard-Tools könnten diese als Fehler kennzeichnen, aber mailcheck ermöglicht die Inspektion dieser Zertifikate gegen TLSA-Einträge und unterstützt so sichere interne Architekturen, die nicht auf öffentlichen Vertrauenskettens beruhen. Dies macht es zu einem wertvollen Asset für hybride Umgebungen, in denen einige Mail-Flows öffentlich und einige privat sind.

Was Sie tun können

• Installieren Sie mailcheck aus dem Forgejo-Repository und führen Sie es gegen Ihre Domain aus, um Ihren aktuellen Stand der E-Mail-Sicherheit zu ermitteln.
• Verwenden Sie das Flag --dkim mit bekannten Selectors, um zu überprüfen, ob Ihre öffentlichen Schlüssel korrekt veröffentlicht und richtig formatiert sind.
• Integrieren Sie das Tool in Ihre CI/CD-Pipeline oder Ihr Monitoring-System unter Verwendung seiner Nagios-kompatiblen Exit-Codes für automatisierte Warnungen.
• Zeigen Sie das Flag --dns auf einen vertrauenswürdigen validierenden rekursiven Resolver, wenn Sie eine genaue DNSSEC-Statusberichterstattung für DANE benötigen.
• Testen Sie die TLS-Konfiguration Ihres SMTP-Servers, indem Sie sicherstellen, dass er mindestens TLS 1.2 unterstützt, da ältere Versionen die Prüfung nicht bestehen.
• Prüfen Sie die Liste der vorgeschlagenen zukünftigen Erweiterungen, um die aktuellen Einschränkungen zu verstehen, wie etwa das Fehlen einer vollständigen rekursiven SPF-Auswertung.