Schlagwort-Archive: OpenDKIM

OpenDKIM is a community effort to develop and maintain a C library for producing DKIM-aware applications and an open source milter for providing DKIM service.

Sender Policy Framework

Sender Policy Framework und Postfix

Mailserver (MTA) benötigen neben einem A Record, dem MX und dem PTR Eintrag, zusätzlich auch einen SPF-Datensatz im DNS.

Was sind SPF-Records

SPF (Sender Policy Framework) ist ein Verfahren zur Sender-Authentifizierung. SPF ist wie DKIM ein Datensatz vom Typ TXT des DNS, die dazu beitragen sollen, E-Mail-Spoofing zu verhindern und bei der Zustellung der eigenen E-Mails diese als legitim zu identifizieren. Auch soll verhindert werden das E-Mails beim Empfänger nicht im Junk-Mail-Ordner landen. Wenn eine Domain durch E-Mail-Spoofing missbraucht wird, landen die E-Mails wahrscheinlich im Spam-Ordner des Empfängers.

Der SPF-Record gibt an, welche Hosts oder IP-Adressen E-Mails im Namen einer Domain senden dürfen. Sie sollten nur dem eigenen Mailserver oder dem Server des Internetdienstanbieters erlauben, E-Mails für diese Domain zu senden.

SPF-Datensatz im DNS Erstellen

Ein SPF-Record ist ein DNS-Eintrag der zur DNS-Zone einer Domain hinzugefügt wird. Der SPF-Eintrag in einer DNS-Zone kann wie folgt aussehen:

Bei der Domain-Verwaltung eines Internet-Webhosting Anbieter kann dies dann etwa wie folgt aussehen.

  • TXT zeigt an, dass dies ein TXT-Datensatz ist.
  • v=spf1 gibt an, dass dies ein SPF-Datensatz ist und die SPF-Datensatzversion SPF1 ist.
  • mx bedeutet, dass alle in den MX-Datensätzen aufgeführten Hosts E-Mails für die Domain senden dürfen, alle anderen Hosts sind nicht zugelassen.
  • ~all gibt an, dass E-Mails dieser Domain nur von Hosts stammen sollen, die im SPF-Datensatz angegeben sind. Von anderen Hosts gesendete E-Mails werden als gefälscht gekennzeichnet. Mögliche Alternativen sind +all, -all, ?all, diese jedoch selten verwendet werden.

Zur Überprüfung das der SPF-Record im öffentlichen Internet aufgelöst wird, ist das Dienstprogramm dig auf dem Linux Host wie folgt zur Abfrage anzuwenden:

An einem Windows Computer kann nslookup in einer Eingabeaufforderung (cmd) ausgeführt werden, die Änderung kann je nach TTL eine Verzögerung haben:

In der PowerShell dient Resolve-DnsName mit folgendem Befehl:

Es können auch Online SPF-Validator wie mxtoolbox verwendet werden, um zu überprüfen welche Hosts die E-Mails der eigenen Domain senden dürfen.

Postfix SPF Policy Agent pypolicyd-spf

Wir benötigen für unseren Postfix SMTP-Server noch die Anweisung, den SPF-Datensatz eingehender E-Mails zu überprüfen, um gefälschte E-Mails zu erkennen. Installiere hierzu als root das Paket pypolicyd-spf aus dem EPEL-Repository:

Füge dann einen Benutzer für Policyd-SPF hinzu:

Bearbeite nun die Postfix-Master-Konfigurationsdatei master.cf:

Füge die Zeilen am Ende der Datei master.cf hinzu, hierdurch wird Postfix angewiesen den SPF-Richtliniendämon zu starten. Policyd-SPF wird als Benutzer policyd-spf ausgeführt.

  Policyd-SPF sollte nicht in einer chroot-Umgebung ausgeführt werden.

Speichere und schliesse nun die Datei. Bearbeite als Nächstes die Postfix-Hauptkonfigurationsdatei main.cf:

Die Zeile mit policyd-spf sollte nach reject_unauth_destination zu stehen kommen. Speichere anschlissend die Datei und starte dann Postfix neu:

Wenn jetzt das nächste Mal eine E-Mail von deiner Domain mit einem SPF-Record empfangen wird, werden die SPF-Prüfergebnisse im raw E-Mail-Header angezeigt. Der folgende Header gibt an, dass der Absender der E-Mail von einem autorisierten Host gesendet wurde.

Postfix protokolliert mit syslog die SPF-Prüfergebnisse in maillog in etwa wie folgt.

450 4.7.1 Helo command rejected: Host not found

Mailserver prüfen bei eingehenden E-Mails den Reverse-Eintrag (PTR) der IP-Adresse vom sendenden Server. Stimmt der Hostname nicht mit der IP Adresse des absendenden Mailservers überein, wird das E-Mail mit der Fehlermeldung 450 4.7.1 abgewiesen.

NOQUEUE reject 450 4.7.1

Im Maillog wird mit NOQUEUE reject 450 4.7.1, hier durch Postfix wie folgt protokolliert.

In diesem Fall muss der Absender prüfen, ob die IP-Adresse seines Mailservers in der DNS Zone mit dem entsprechenden PTR-Record übereinstimmt.

Ist der sendende Mailserver bekannt und vertrauenswürdig, kann Postfix angewiesen werden eine Ausnahme durch die EHLO/HELO Überprüfung zu veranlassen.

Dazu wird eine Datei helo_access angelegt, mit folgendem Inhalt.

Danach postmap ausführen um die hash db zu erzeugen.

Postfix muss die Änderung zur Aktivierung noch übernehmen.

Im maillog kann nun überprüft werden ob die Emails angenommen werden. Mit mailq wird festgestellt ob sich noch nicht zugestellte Emails in der Queue befinden, und mit der Eingabe postqueue das zustellen gleich ausgelöst, mit tail wird das maillog geöffnet.

Oft sind es falsch konfigurierte Exchange Server die sich mit falschem, internen hostname melden, den korrekten FQDN stellt man in der ECP Konsole ein, beim zuständigen FrontendTransport Connector.

Besser noch man lässt den Exchange Server über ein Smarthost seine Mails versenden, dadurch bietet sich die Möglichkeit ausgehende Mails zusätzlich mit DKIM im Envelop zu versenden, was die Authentizität erhöht, und bei eingehenden Mails eine wirksame SPAM und Schadcode Filterung ermöglicht, etwa durch SpamAssassin oder mit Amavis-new.

DKIM mit OpenDKIM und Postfix auf CentOS

DKIM für Domain Keys Identified Mail

DKIM fügt den Mails eine eindeutige Signatur hinzu, die sich der Domain zuordnet und für alle Nachrichten benutzt wird die versendet werden. Dies hilft dem Internet Service Provider (ISP) bei der Kontrolle der Authentizität der E-Mails und garantiert für die Integrität der Nachrichten.

Ursprünglich sollte das Verfahren DomainKeys Identified Mail nur die Spam-Flut eindämmen. Doch da es gefälschte Absenderadressen entdeckt, hilft es besser gegen Phishing.

OpenDKIM ist die Open-Source Technologie unter Linux für digitale E-Mail-Signatur und Verifikation, die bereits von namhaften E-Mail-Anbieter unterstützt wird.

In diesem Artikel wird beschrieben wie OpenDKIM auf CentOS 5/6/7 integriert und konfiguriert wird.

Das EPEL-Repository wird zur Installation benötigt, falls dieses nicht schon auf dem System integriert ist, wird folgendes vorgehen ausgeführt.

CentOS 5.x Extras Repository
wget -P /tmp https://dl.fedoraproject.org/pub/epel/epel-release-latest-5.noarch.rpm
sudo rpm -Uvh /tmp/epel-release-5*.rpm

CentOS 6.x Extras Repository
wget -P /tmp https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
sudo rpm -Uvh /tmp/epel-release-6*.rpm

CentOS 7.x Extra Repository
yum -y install epel-release

Nun kann OpenDKIM auf dem Server installiert werden.

Nach dem OpenDKIM installiert ist, wird die Hauptkonfiguration erstellt. Dabei wird die original Datei opendkim.conf vor dem editieren erst kopiert.

cp /etc/opendkim.conf /etc/opendkim.conf.orig
vi /etc/opendkim.conf

Nun werden die Verzeichnisse und ein DomainKey für die Beispiel Domain maildomain.ch durch die folgenden vier Eingaben generiert.

Den DomainKey zur maildomain.ch hinzufügen.
vi /etc/opendkim/KeyTable

DomainKey zur Unterzeichnung eintragen.
vi /etc/opendkim/SigningTable

Welche Domains und Hosts sollen DKIM verwenden.
vi /etc/opendkim/TrustedHosts

Den DomainKey auf dem Nameserver als DNS TXT Record zur Zone maildomain.ch hinzufügen. Beispiel: maildomain.txt, zu beachten ist, das die Key Zeile auf einer Linie zu stehen kommt.

Und wenn wir schon dabei sind, kann auch gleich ein TXT Record für SPF, Sender Policy Framework hinzugefügt werden.

Mit dem domain information groper – dig lässt sich ein query des DomainKey mit folgender Eingabe ausgeben.

Bei Postfix muss noch der milter integriert werden. Das Domain signing wird zum SMTP-Header hinzugefügt und über Port 8899 an Postfix zurückgegeben.

vi /etc/postfix/main.cf

Dann die Services starten.

Mit einem Test Mail an check-auth@verifier.port25.com wird die DKIM Signatur überprüft und das Resultat gleich als Antwort zurück gesendet. Das Ergebnis sollte dann in etwa wie folgt aussehen.


Quellen Links:
DomainKeys Wiki