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.