IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: DKIM (Seite 2 von 2)

RBL und DNSBL in Postfix: Spam auf Verbindungsebene abweisen

Realtime Blackhole Lists (RBL) bzw. DNS-based Blackhole Lists (DNSBL) sind eine der ältesten und effektivsten Methoden gegen Spam. Das Prinzip ist simpel: Der sendende Server wird gegen eine Liste bekannter Spam-Quellen geprüft, noch bevor die Mail angenommen wird. Steht die IP auf der Liste, wird die Verbindung sofort abgelehnt. Der Server muss die Mail gar nicht erst annehmen, filtern oder speichern.

Vorteile und Nachteile

Der große Vorteil: Die Abweisung passiert auf SMTP-Ebene, bevor Ressourcen verschwendet werden. Bei hohem Mailaufkommen macht das einen spürbaren Unterschied. 80 bis 90 Prozent des Spam-Verkehrs lassen sich so schon beim Verbindungsaufbau abfangen.

Der Nachteil: Man verlässt sich auf Dritte. Wer auf einer RBL landet, kommt nicht immer schnell wieder runter. Und wenn ein RBL-Betreiber seinen Dienst einstellt, kann das zu Problemen führen (dazu weiter unten mehr). RBLs ersetzen keinen Content-Filter, sie ergänzen ihn.

Postfix konfigurieren

Die RBL-Abfragen werden in smtpd_recipient_restrictions in der main.cf eingetragen. Zwei Typen:

reject_rbl_clientPrüft die IP-Adresse des sendenden Servers gegen die Liste
reject_rhsbl_senderPrüft die Domain des Absenders (rechte Seite der Adresse) gegen die Liste

Eine bewährte Kombination:

# /etc/postfix/main.cf (Auszug)
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client ix.dnsbl.manitu.net

zen.spamhaus.org ist die wichtigste Liste. Sie fasst mehrere Spamhaus-Listen zusammen (SBL, XBL, PBL) und deckt bekannte Spammer, Exploits und dynamische IP-Bereiche ab. bl.spamcop.net reagiert schnell auf aktuelle Spam-Wellen. ix.dnsbl.manitu.net (NiX Spam) ist eine deutsche Liste die besonders gut bei deutschsprachigem Spam funktioniert.

Die Reihenfolge ist wichtig: permit_mynetworks und permit_sasl_authenticated müssen vor den RBL-Checks stehen, damit eigene Benutzer und authentifizierte Verbindungen nicht gegen die Listen geprüft werden.

Tote RBL-Server erkennen

Stellt ein RBL-Betreiber seinen Dienst ein, werden DNS-Anfragen entweder nicht beantwortet oder liefern für jede IP einen Treffer zurück. Beides ist schlecht. Im ersten Fall laufen die Anfragen in Timeouts und bremsen alle DNS-Auflösungen aus. Im zweiten Fall wird plötzlich jede eingehende Mail abgewiesen.

Im Postfix-Log (/var/log/mail.log) erkennt man das an Timeout-Warnungen oder an plötzlich massenhaften Ablehnungen. Die Lösung: Tote Listen sofort aus der Config entfernen. Es lohnt sich, die RBL-Listen alle paar Monate zu prüfen. Bekannte Leichen aus der Vergangenheit: dnsbl.njabl.org (2013 abgeschaltet), rhsbl.ahbl.org (2015 abgeschaltet), dnsbl.sorbs.net (mehrfach instabil).

RBL-Ablehnungsmeldung anpassen

Standardmäßig schickt Postfix eine generische Fehlermeldung. Mit default_rbl_reply lässt sich eine aussagekräftigere Antwort konfigurieren, die dem Admin des sendenden Servers hilft:

default_rbl_reply = $rbl_code Service unavailable; $rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}

RBL und rspamd

Wer rspamd einsetzt, kann RBL-Checks auch dort konfigurieren statt in Postfix. rspamd fragt die Listen asynchron ab und verrechnet das Ergebnis mit dem Gesamtscore der Mail. Das ist flexibler als die harte Ablehnung in Postfix: Eine IP auf einer einzelnen Liste führt nicht sofort zur Ablehnung, sondern erhöht den Spam-Score. Erst wenn mehrere Indikatoren zusammenkommen, wird die Mail abgewiesen.

Beide Ansätze lassen sich auch kombinieren: Die wichtigsten Listen (Spamhaus) direkt in Postfix für die sofortige Ablehnung, weitere Listen in rspamd für die feinere Bewertung.

RBLs sind ein Baustein im Gesamtsystem. Zusammen mit SPF, DKIM und DMARC decken sie verschiedene Angriffsvektoren ab. Fragen? Einfach melden.

DKIM einrichten: E-Mails signieren und verifizieren mit rspamd und Postfix

DKIM (DomainKeys Identified Mail, RFC 6376) signiert ausgehende E-Mails kryptografisch. Der empfangende Mailserver prüft die Signatur über einen DNS-Record. Stimmt sie nicht, ist die Mail manipuliert oder stammt nicht vom angegebenen Absender. DKIM ist neben SPF und DMARC einer der drei Bausteine moderner E-Mail-Authentifizierung.

Wie DKIM funktioniert

Der sendende Mailserver berechnet einen Hash über definierte Header-Felder und den Body der E-Mail, verschlüsselt diesen Hash mit seinem privaten Schlüssel und hängt das Ergebnis als DKIM-Signature-Header an die Mail. Der empfangende Server holt den öffentlichen Schlüssel per DNS-Abfrage (selektor._domainkey.domain.de), entschlüsselt die Signatur und vergleicht den Hash. Stimmt er überein, ist die Mail authentisch und unverändert.

DKIM-Schlüssel erstellen

RSA mit 2048 Bit ist der Standard. 1024 Bit gilt seit Jahren als zu schwach, nicht mehr verwenden. Ed25519-Schlüssel sind kompakter und schneller, werden aber noch nicht von allen Empfängern unterstützt. Wer auf Nummer sicher gehen will, signiert mit beiden (Dual Signing).

# RSA 2048 Bit (Standard, universell unterstützt)
openssl genrsa -out /var/db/rspamd/dkim/2026.key 2048
chmod 640 /var/db/rspamd/dkim/2026.key
chown _rspamd:_rspamd /var/db/rspamd/dkim/2026.key

# Öffentlichen Schlüssel extrahieren (für den DNS-Record)
openssl rsa -in /var/db/rspamd/dkim/2026.key -pubout -out /var/db/rspamd/dkim/2026.pub

Der Selektor (hier 2026) ist frei wählbar. Gängige Konvention: Jahr oder Monat als Selektor, das erleichtert die Key-Rotation.

DNS-Record veröffentlichen

Der öffentliche Schlüssel wird als TXT-Record im DNS veröffentlicht. Der Recordname folgt dem Schema selektor._domainkey.domain.de:

2026._domainkey.kernel-error.de. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq...langer-Base64-String...IDAQAB"

Den Base64-String aus der .pub-Datei nehmen, ohne Header/Footer-Zeilen und Zeilenumbrüche, alles in eine Zeile. Bei BIND-Zonefiles auf die 255-Zeichen-Grenze pro TXT-String achten. Längere Schlüssel müssen in mehrere Strings aufgeteilt werden (BIND macht das automatisch, wenn man den Record in Anführungszeichen setzt).

rspamd als DKIM-Signer konfigurieren

rspamd bringt DKIM-Signing und -Verification von Haus aus mit, kein zusätzliches Paket nötig. Die DKIM-Signing-Dokumentation beschreibt alle Optionen. Für eine einfache Konfiguration mit einem Schlüssel pro Domain:

# /usr/local/etc/rspamd/local.d/dkim_signing.conf

allow_username_mismatch = true;

domain {
    kernel-error.de {
        path = "/var/db/rspamd/dkim/2026.key";
        selector = "2026";
    }
}

# Nur lokal eingelieferte Mails signieren (SASL-authentifiziert)
sign_authenticated = true;
sign_local = true;

Nach einem service rspamd reload signiert rspamd alle ausgehenden Mails. Die Verification eingehender Mails ist standardmäßig aktiv. Das DKIM-Modul läuft automatisch und fließt in den rspamd-Score ein. Wer rspamd auch für automatisches Spam/Ham-Lernen nutzt, hat damit eine Lösung für beides.

Alternative: opendkim

Wer kein rspamd einsetzt, kann opendkim als Milter in Postfix einbinden. Die Konfiguration ist etwas aufwändiger (eigener Daemon, Socket, Milter-Einbindung in main.cf), funktioniert aber zuverlässig. Die Schlüsselerstellung und DNS-Konfiguration sind identisch.

DKIM testen

Ob der DNS-Record korrekt veröffentlicht ist:

# DNS-Record abfragen
dig TXT 2026._domainkey.kernel-error.de +short

# Mit rspamd testen (wenn lokal installiert)
rspamadm dkim_keygen -d kernel-error.de -s 2026 -k /var/db/rspamd/dkim/2026.key --check

Den einfachsten Funktionstest macht man, indem man eine Mail an eine Adresse bei Gmail oder Outlook schickt und dort die Header prüft. Im Header der empfangenen Mail steht dann:

Authentication-Results: mx.google.com;
    dkim=pass header.d=kernel-error.de header.s=2026

dkim=pass bedeutet: Signatur gültig, Schlüssel im DNS gefunden, Hash stimmt überein.

Key-Rotation

DKIM-Schlüssel sollten regelmäßig getauscht werden. Einmal pro Jahr ist ein guter Rhythmus. Der Ablauf:

  • Neuen Schlüssel mit neuem Selektor erstellen (z.B. 2027)
  • Neuen DNS-Record veröffentlichen
  • rspamd auf den neuen Selektor umstellen
  • Alten DNS-Record noch 30 Tage stehen lassen (für Mails die noch in Queues liegen)
  • Alten Record löschen

Durch die Selektoren können alter und neuer Schlüssel parallel im DNS existieren. Empfänger prüfen immer den Selektor aus dem DKIM-Signature-Header, es gibt keine Unterbrechung.

DKIM allein reicht nicht

DKIM beweist nur, dass eine Mail von einem bestimmten Schlüssel signiert wurde, nicht dass der Absender im From:-Header berechtigt ist, diese Domain zu nutzen. Dafür braucht es die anderen Bausteine:

  • SPF — definiert per DNS, welche IP-Adressen für eine Domain Mails versenden dürfen
  • DMARC — verknüpft SPF und DKIM mit einer Policy: Was soll der Empfänger tun, wenn beides fehlschlägt?
  • DANE/TLSA — sichert den Transportweg per DNSSEC ab

Siehe auch: internet.nl: Mailserver-Sicherheit testen mit dem niederländischen Standard

Erst alle drei zusammen (SPF, DKIM und DMARC) ergeben eine vollständige E-Mail-Authentifizierung. Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑