DNS-Checks

1. Absender-Adresse

Zusätzlich zu den RBL-Domain-Checks wird die Domain der Absender-Mailadresse  auf Existenz geprüft. Existiert die Domain nicht, wird die Mail abgelehnt. Auf Wunsch können weitere Checks aktiviert werden:

  • Der MX-Record der Absenderdomain ist nicht umgebogen auf localhost bzw. eine IP-Adresse, die nicht weltweit geroutet wird (private, link-local, reserverd, tests, multicast, etc).
  • Die Absenderadresse existiert in einer lokalen Whitelist.
  • Die Absenderadresse wird auf Existenz über die Address-Verification analog der Empfänger-Verifikation geprüft (nur eigene Domains).

2. DANE

Der Check findet immer im versendenden Mailserver statt, d.h. bei uns im ausgehenden Mailverkehr. Der Empfänger muss jedoch mithelfen, indem er DNSSEC benutzt und TLSA-Records veröffentlicht.

a. Der Standard bei uns ist opportunistic DANE. Es wird überprüft, ob die MX-Records der Empfängerdomain sowie die A-/AAAA-Records der Mailserver DNSSEC-geschützt sind. Ist dies der Fall, so wird geprüft, ob für die A-/AAAA-Records TLSA-Records existieren. Ist dies auch der Fall, so wird die Mail nur übertragen, wenn der empfangende Mailserver TLS anbietet und dessen Zertifikat sich mit der Checksumme aus dem TLSA-Record verifizieren lässt. Fehlt DNSSEC oder fehlen die TLSA-Records, so wird die Mail normal übertragen (TLS, wenn angeboten, ansonsten Klartext).

b. Auf Wunsch kann für eine von Ihnen zu liefernde Liste von Empfänger-Domains mandatory DANE  aktiviert werden. Mails an diese Empfänger werden nur dann zugestellt, wenn DNSSEC und TLSA-Records vorhanden und der DANE-Check erfolgreich durchlaufen wurde.

In folgender Tabelle sind die Schritte des DANE-Checks aufgelistet sowie das daraus resultierende Verhalten des postfix:

  opportunistic DANE mandatory DANE
1. DNS- bzw. DNSSEC-Fehler treten auf defer defer
2. MX-Records sind nicht DNSSEC geschützt may defer
3. A-/AAAA-Records sind nicht DNSSEC geschützt may defer
4. TLSA-Records sind nicht vorhanden may defer
5. Inhalt des TLSA-Records ist nicht verwertbar mandatory TLS defer
6. Server bietet kein TLS-Zertifikat an defer defer
7. Zertifikat passt nicht zu TLSA-Records defer defer
8. DANE-Check bestanden TLS-gesicherte Übertragung der Mail

Erläuterung:

defer Die Mail wird in die Queue zurückgestellt. In gewissen Zeitabständen wird ein neuer Versuch gestartet, wobei alle Schritte nochmals durchlaufen werden. Nach fünf Tagen erfolgloser Versuche geht die Mail als unzustellbar an den Absender zurück.
may Bietet der Empfänger-Mailserver ein TLS-Zertifikat an, so wird dieses ohne nähere Prüfung zur Verschlüsselung verwendet. Wird kein Zertifikat angeboten, so wird die Mail unverschlüsselt übertragen.
mandatory TLS Die Mail wird nur übertragen, wenn der Empfänger-Mailserver ein TLS-Zertifikat anbietet. Dieses wird ohne nähere Prüfung zur Verschlüsselung verwendet.

Tests

Ob für einen Mailserver ein DANE-Record im DNS existiert und ob dieser zum aktuellen Zertifikat des Mailservers passt, kann man lokal mit dem postfix-Test-Kommando posttls-finger testen:

            $ posttls-finger -L debug a1001.mx.srv.dfn.de | less
posttls-finger: DNSSEC-signed TLSA record: _25._tcp.a1001.mx.srv.dfn.de: 3 0 1 B85BD6FA275E5DE5748964BFBEBA198836ABAE5D6BF51A7D75756F888B3C08E7
posttls-finger: DNSSEC-signed TLSA record: _25._tcp.a1001.mx.srv.dfn.de: 3 0 1 C613B846076B55038B254F4AD7B6118509FF00DABF31743F539E7AC79A3F13E9
posttls-finger: Connected to a1001.mx.srv.dfn.de[194.95.233.3]:25
...
posttls-finger: a1001.mx.srv.dfn.de[194.95.233.3]:25: Matched DANE EE certificate at depth 0: 3 0 1 B85BD6FA275E5DE5748964BFBEBA198836ABAE5D6BF51A7D75756F888B3C08E7
...
$
        

Alternativ können Sie auch eines der hier gelisteten Webtools verwenden.