Plesk Obsidian für Linux E-Mail Schutz aktivieren

Plesk Obsidian bietet die gängigen Schutzverfahren: DKIM, SPF, DMARC und DNSBL. Um sie einzusetzen, muss man einiges darüber wissen und einiges dafür tun. Hier eine Anleitung dafür.

Vorweg: Die Plesk Seiten dazu für Administratoren und Benutzer. Da wird klargestellt, dass unter Plesk für Linux nur Postfix (SMTP MTA – Mail Transfer Agent) alle Verfahren unterstützt.

Ferner vorweg, ein sehr übersichtlicher Artikel zu DKIM (und SPF), und warum gerade kleine Mail-Provider (typische Plesk-Kunden) sie ja einsetzen sollen! Nämlich: Sonst werden von den großen Providern Google, GMX, Microsoft, Yahoo usw. die E-Mails von den kleinen Servern zu oft als Spam abgewiesen. Dies entspricht auch meiner Erfahrung – sobald ich SPF UND DKIM implementiert hatte, kamen auf einmal (endlich) meine E-Mails bei Gmail sofort an (im Posteingang, kein Spam).

Hintergrund: Envelope Sender

In Ihrem E-Mail Client verfassen Sie eine E-Mail mit den Pflichtfeldern „From“ und „To“ (Von und An). Solche Angaben, die nicht zum Text der E-Mail gehören, wie auch z.B. der Betreff, werden gesammelt als „Headers“ (Kopfzeilen) gruppiert und vor dem „Body“ (Rumpf) mitgeschickt.

Ihr E-Mail Client reicht beim Absenden die E-Mail beim SMTP-Dienst am für Ihre E-Mail Domain zuständigen SMTP-Server ein. Ihr SMTP-Dienst (aus diesem Blickwinkel der „SMTP-Client“) versieht die E-Mail beim Senden an den für die Domain des E-Mail Empfängers zuständigen „SMTP-Server“ mit einem sogenannten „Umschlag“ (Engl.: Envelope Sender), ähnlich wie physischen Briefe bei der „gelben Post“. Dieser virtuelle Umschlag besteht einfach aus drei Befehlen vom SMTP-Client an den SMTP-Server:

  • MAIL FROM
    Die E-Mail Adresse, an die die E-Mail bei Nichtzustellbarkeit zurückgesandt werden soll.
    Falls in den E-Mail Headers ein „Reply-To“ (Antworten an) Header vorliegt, wird diese Adresse genommen, ansonsten die Adresse aus dem „From“ Header.
  • RCPT TO
    Die E-Mail Adresse des Empfängers. Der Befehl kann wiederholt werden für mehrere Empfänger.
  • DATA
    Kopzeilen und Rumpf der E-Mail selbst, durch eine Leerzeile getrennt.

Spammer können allerdings mit manipulierter SMTP-Software die FROM-Adresse im Umschlag anders setzen als die Angaben in den Kopfzeilen der E-Mail selbst. Es besteht im SMTP-Verfahren keine Kontrolle darüber, ob die Angaben übereinstimmen.

Resourcen:
Wikipedia zu SMTP
Envelope und Headers, Spamming
Email addressing (Englisch)
E-Mail-Header

DKIM: DomainKeys Identified Mail

Artikel dazu in Wikipedia (eher schwerverständlich), hier kurz und übersichtlich, und von Heise sehr ausführlich, und hier ganz knapp. Fazit: DKIM erfolgt ausschließlich auf Server-Ebene, der sendende SMTP-Server fügt eingelieferte E-Mails Kopfzeilen hinzu, mit einer verschlüsselten Signatur, deren „Public Key“ in einem DNS-Eintrag der Domain hinterlegt ist. Dies erlaubt es dem empangenden SMTP-Server festzustellen, (a) dass der sendende Server tatsächlich der Mailexchanger der Domain des Absenders ist, sowie (b) ob der Inhalt (und Kopfzeilen) der E-Mail unverändert sind.

DKIM bezieht sich also auf die „From“ Kopfzeile der E-Mail. Das ‚MAIL FROM‘ Feld im SMTP-Umschlag (siehe oben) spielt hier keine Rolle.

Wer wie ich seine E-Mail-Konten auf eigene Server hostet, ist mit DKIM gut bedient. DKIM wird von den großen öffentlichen Providern wie gmail, gmx und co. selbstverständlich eingesetzt bzw. bedient, doch ist hier der Nutzen geringer, denn Spammer und Phisher können auch dort (für kurze Zeit) Konten eröffnen )-:

Die Schritte zur vollständigen Einrichtung von DKIM hängen davon ab, ob die DNS-Einträge der Domain auf dem Plesk-Server selbst verwaltet werden, oder bei einem externen Domain-Hoster. Im ersten Fall kann Plesk den nötigen DNS-Eintrag mit dem Public Key selbst setzen; im zweiten Fall muss man das selbst machen. So geht es:

  • Tools und Einstellungen | Mailserver-Einstellungen
  • Herunterscrollen bis zum Abschnitt DKIM
  • Dort beide Checkboxen setzen (Ausgehende und eingehende E-Mails)
  • Vorsicht: Das Signieren aller ausgehender E-Mail-Nachrichten wird dabei nicht automatisch aktiviert. Um DKIM zu verwenden, müssen Benutzer DKIM für die einzelnen Domains aktivieren. Im Gegensatz dazu: alle eingehenden E-Mails werden in Hinsicht auf DKIM überprüft.
  • Daher: Pro Domain „E-Mail-Einstellungen“ aufrufen, und bei „DKIM-Spamschutzsystem zum Signieren ausgehender E-Mail-Nachrichten verwenden“ das Checkbox aktivieren. OK.
  • Plesk gibt hier leider *kein* Feedback bei extern verwalteten Domains. Dafür verrät ein Support-Artikel auf Englisch, wie man händisch auf Betriebssystemebene den öffentlichen Schlüssel herausbekommt und beim Domain-Hoster in Kraft setzt:
    • Auf den Server per SSH einloggen
    • # cd /etc/domainkeys
    • # cd {domain.tld}
    • # openssl rsa -in ./default -pubout
    • Die Ausgabe des eigentlichen Schlüssels (ohne die „—“ Zeilen) kopieren und die Zeilenumbrüche sorgfältig entfernen, so dass der ganze Schlüssel auf einer Zeile steht. Diesen kopieren und in ein DNS TXT-Record beim Domain-Hoster wie folgt einsetzen:
    • Subdomain: default._domainkey
      Wert: v=DKIM1;k=rsa; p={Key-ohne-Zeilenenden};
      Achtung: den abschließenden Strichpunkt nicht vergessen!
    • Zur Klarstellung: Falls Sie auch eine „mail.“ Subdomain in Plesk angelegt haben, wird auch dafür ein Unterverzeichnis und Schlüsseldatei angelegt. Aber der Schlüssel ist in dem Fall identisch mit dem der Hauptdomain, man kann den „Public Key“ aus irgendeinem der beiden Unterverzeichnisse holen.

Abschließend sollten Sie unbedingt die DKIM-Einrichtung testen: Schicken Sie sich selbst eine E-Mail, von der neu geschützten Domain an eine eigene Adresse mit anderer Domain (z.B. gmail). Im E-Mail Client exportieren Sie die frisch eingetroffene E-Mail als .eml Datei und öffnen Sie die Datei in einem einfachen Text-Editor. Nur so sehen Sie alle „technischen“ Kopfzeilen. Die Kopfzeile „DKIM-Signature:“ enthält die Signatur, die vom sendenden Postfix hinzugefügt wurde, mit folgenden Einträgen:

  • v=1; (Die Versionsnummer des DKIM-Protokolls)
  • a=rsa-sha256; (Der Verschlüsselungsalgorithmus der Signatur)
  • c=relaxed/relaxed; (the canonicalization algorithm(s) for header and body)
  • d=your-from.tld; (die Domain die signiert)
  • s=default; (Selector: Wählt im DNS den zu-verwendenden TXT-Eintrag; dem Selektor wird standardmäßig „._domainkey“ hinzugefügt)
  • t=1577738108; (Timestamp = Zeitstempel der Signatur)
  • bh=… (body hash – der Signaturwert für den Rumpf der E-Mail)
  • b=… (der Signaturwert für die ganze -Mail – Headers + Body)

Die Kopfzeile „Authentication-Results:“ enthält die Aussage des SMTP-Empfängers zur Prüfungsergebnis. Das erste Beispiel wurde von meinem Plesk-Server empfangen, das zweite von Gmail, jeweils die gleiche E-Mail von timreeves.de:

Je nach Konfiguration / Aufrüstung des empfangenden Systems ist mit weiteren relevanten Kopfzeilen zu rechnen. Gmail setzt wohl ein eigenes System „ARC“ ein, welches diverse eigenen Kopfzeilen hinzufügt; Plesk-Server mit aktiviertem SpamAssassin fügen (mitunter) eine „X-Spam-Status:“ Kopfzeile hinzu, die etwa so aussieht:

  • X-Spam-Status: No, score=-0.2 required=7.0 tests=DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE,SPF_HELO_PASS,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2

Aufschlussreich ist darin „SPF_HELO_PASS“, sprich SPF wurde bereits im HELO-Befehl bestanden (s. unten); sowie „URIBL_BLOCKED“ (s. ‚DNSBL‘ ganz unten).

SPF: Sender Policy Framework

SPF ist deutlich einfacher als DKIM, benötigt keine Änderung am sendenden Mailserver, einen DNS-Eintrag, und nur eine einfache Prüfung am empfangenden Mailserver. Hier das definitive Dokument RFC-7208, hier auf Wikipedia (Deutsch) und ein sehr übersichtlicher Artikel auf Englisch. Und hier eine Liste auf Englisch der möglichen Elemente in einem SPF-Eintrag.

In Kürze: Es wird ein DNS TXT-Record für die sendende Domain eingetragen, dessen Inhalt festlegt, welche Mailserver berechtigt sind, E-Mails zu senden von E-Mail-Konten der Domain. Wie bei DKIM, muss der empfangende Mailserver die Prüfung anwenden, doch dies ist bei den großen Providern wie Gmail, GMX und Co. längst der Fall. Und sollte daher auch für Mailempfang auf von Plesk verwalteten Servern eingeschaltet werden.

Im Gegensatz zu DKIM, das sich lediglich auf die Domain der Absenderadresse in der Kopfzeile der E-Mail bezieht, wird SPF auf die Befehle im E-Mail Umschlag des SMTP-Protokolls angewandt. Bei SPF soll der Empfänger, zusätzlich zur Domain des Absenders im „MAIL FROM“ Befehl, auch die Domain im „HELO/EHLO“ Befehl zum Auftakt der SMTP-Verbindung prüfen – beide sollen IPs aufweisen, die durch den (jeweiligen) SPF-Eintrag erlaubt sind. Es muss sich dabei nicht um die gleiche Domain handeln, denn ein SMTP-Server kann für viele Domains arbeiten, und was er in seinem HELO setzt ist konfigurierbar. Sind die Domains in beiden Fällen gleich, so muss der empfangende Mailserver nur einen DNS-Eintrag holen.

Bei SPF wird an bis zu zwei Kennwerten geprüft, ob der „richtige“ Server die E-Mail gesendet hat. Bei DKIM wird das für die Absender-Domain aus den Kopfzeilen geleistet, und dafür zusätzlich die Prüfung auf Unversehrtheit von Kopf und Körper der E-Mail. Es ist daher gut, beide Verfahren einzusetzen – doppelt hält besser – weil (a) nicht alle empfangende Mailserver beide Prüfungen durchführen; (b) andere empfangende Mailserver wiederum so „scharf“ eingestellt sind, dass man das Risiko der irrtümlichen Einstufung dort als Spam mindert; (c) man dann die Option hat, das DMARC-Verfahren zusätzlich einzusetzen.

Kontrolle ob bei einer bestimmten E-Mail SPF angewendet wurde: Schalten Sie in Ihrem E-Mail Client die Anzeige aller Kopfzeilen ein. Meist wird es eine Kopfzeile bzgl. Spam-Einstufung geben, z.B. von „SpamAssassin“, wie „X-Spam-Status“. Darin etwas wie: SPF_HELO_NONE,SPF_PASS. Das „SPF_HELO_NONE“ bedeutet dass (soweit SpamAssassin weiss) beim SMTP HELO-Befehl keine SPF-Prüfung durchgeführt wurde (womöglich gab es im HELO nur die IP-Angabe und keine Domain-Angabe). Ich habe aber auch gesehen: SPF_HELO_PASS,SPF_NONE. Offensichtlich erfolgte hierbei eine SPF-Prüfung auf einer Domainangabe im HELO-Befehl, und daraufhin wurde auf einer weiteren Prüfung beim MAIL From-Befehl verzichtet (womöglich war in beiden Fällen die Domain identisch). Auch beobachtet: SPF_HELO_PASS,SPF_SOFTFAIL – in diesem Fall hat der SMTP-Client (Im HELO-Befehl) den SPF-Test bestanden, aber für die Domain des Absenders sind keine SPF-Einträge veröffentlicht.

SPF hat aber auch seine Probleme:

TODO

Plesk SPF-Einstellungen konfigurieren:

  • Tools und Einstellungen | Mailserver-Einstellungen
  • Herunterscrollen bis zum Abschnitt SPF
  • SPF-Spamschutz aktivieren, um eingehende E-Mails zu überprüfen: Häkchen setzen
  • SPF-Überprüfung fortsetzen, wenn es Probleme mit der DNS-Suche gibt: Diese Option ist bei den ersten beiden Optionen in der darunterstehenden Dropdown-Liste unwirksam und daher ausgegraut.
  • SPF-Prüfmodus: Hier stehen mehrere Möglichkeiten in einer Dropdown-Liste zur Auswahl. Um diese Entscheidung zu treffen, muss die restliche Softwareumgebung und die eigenen Anforderungen herangezogen werden (hier es gibt kein „one size fits all“):
    • Nur Received-SPF-Header erstellen, niemals blockieren
      Only create Received-SPF headers, never block
      Wählen Sie diese Option (Default, und auch von mir empfohlen) wenn Sie eine Entscheidung über Spam dem nachgelagerten SpamAssassin überlassen möchten. Womöglich müssen Sie dann bewusst die SpamAssassin-Regeln anpassen. In Plesk: Tools und Einstellungen | Spamfilter-Einstellungen | Die Bewertung, die einer Nachricht zugewiesen werden muss, um als Spam angesehen zu werden (Default: 7.00, Probiere: 5.00).
    • Benachrichtigungen über temporäre Fehler verwenden, wenn Probleme bei der DNS-Suche auftreten
      Use temporary error notices when you have DNS lookup problems

      Achtung: Die Wirkung dieser Einstellung ist wenig intuitiv. Alle eingehenden Nachrichten werden ungeachtet der Ergebnisse der SPF-Überprüfung angenommen, selbst wenn die SPF-Prüfung aufgrund von Problemen bei der DNS-Suche fehlgeschlagen ist.
    • Vier weiteren Optionen betreffen die Abweisung eintreffender E-Mails, je nach Ergebnis der SPF-Prüfung. Ich finde diesen Weg an sich gefährlich, und wenn, dann musste man lokale Ersatzregeln festlegen, die zu benutzen sind wenn die Domain kein eigener SPF-Eintrag enthält oder per DNS gerade nicht erreichbar ist. Für mich wäre das „zu scharf“ eingestellt, und vor allem einseitig, die Einstufung würde sich zu stark nach SPF orientieren. Meines Erachtens ist es besser, das nachgelagerte SpamAssassin die Entscheidung zu überlassen – aufgrund einer vielzahl von Kriterien.

Resourcen:
SPF bei Wikipedia (ausführlich aber verständlich)
SPF bei Google (mittlerer Länge)
SPF bei United Domains (kurz)
Plesk-Forum: Block Spam Mails sent from own Domain

SRS: Sender Rewriting Scheme

Das Sender Rewriting Scheme (kurz SRS) ist eine Methode, um den Absender (genauer: den Envelope Sender) einer E-Mail so umzuschreiben, dass Sender Policy Framework (SPF) auch mit Mail-Umleitung funktioniert. Siehe hierzu Wikipedia Sender Rewriting Scheme. Aus Sicht eines Mailversenders ist SRS eine unbefriedigende Lösung, da er zwar mit SPF bestimmen kann, welche Server mit der eigenen Absenderadresse senden dürfen, er aber darauf angewiesen ist, dass alle weiterleitenden Mailserver SRS implementieren, damit die Mail sicher zugestellt wird, was außerhalb seines Einflussbereiches liegt. Ungeachtet dieser Problematik teilt die Plesk-Dokumentation mit: SRS wird automatisch verwendet, wenn Nachrichten von in Plesk gehosteten Postfächern weitergeleitet werden.

DMARC

TODO

Weitere Themen

Postausgangsmodus

Unter „Tools & Einstellungen | Mailserver-Einstellungen | Allgemeine Optionen | Postausgangsmodus“ (Outgoing mail mode) bietet Plesk drei Optionen, wie der SMTP-Dienst (Postfix) sich im HELO-Befehl verhalten soll:

  • Über Domain-IP-Adressen senden
  • Über Domain-IP-Adressen senden und Domainnamen in SMTP-Begrüßung verwenden
  • Über die angegebenen IP-Adressen senden

Die dritte Möglichkeit macht nur Sinn auf Server mit mehr als einer IP-Adresse. Ich selbst verwende die Option „und Domainnamen in SMTP-Begrüßung verwenden“ – nach der Annahme dass es überzeugender für den SMTP-Empfänger ist, wenn die HELO-Domain mit der „From“ Domain übereinstimmt, und nur eine SPF-Prüfung stattfinden muss (ansonsten könnte / müsste der SMTP-Empfänger beide Domains bzgl. SPF prüfen).

Die Plesk-Dokumentation indes empfiehlt die erste Option und warnt bei der zweiten: Wenn Sie diese Option auswählen, werden E-Mails von einigen oder allen Domains möglicherweise als Spam markiert, wenn der E-Mail-Zielserver cbl verwendet und mehr als eine Domain auf dem Plesk Server die gleiche IP-Adresse verwendet. Demnach haben beide Optionen einen Nachteil, ich vermag hier keine klare Empfehlung zu geben.

DNSBL: DNS-based Blackhole List

Grundsätzlich eine gute Idee: Diverse Organisationen stellen sog. „Schwarze Listen“ zur Verfügung, von IP-Adressen die als Absender von Spam aufgefallen sind. Es wäre nicht verkehrt, sich bei den Solidesten davon zu bedienen als Teil einer umfassenden Spamprüfung. Das Problem ist, dass sie die Information mittels DNS-Einträge zur Verfügung stellen, und die Anzahl (kostenloser) Anfragen pro DNS-Server begrenzen, damit sie selbst nicht von (kostenlosen) Anfragen überschwemmt werden. Wer die DNS-Server seines Hosting-Providers verwendet wird feststellen, dass sie von den Blackhole-Servern blockiert sind. Einziger Ausweg ist, auf dem eigenen (virtuellen) Server einen Caching-DNS Dienst einzurichten. Dafür hatte ich bis jetzt leider keine Zeit )-:

Resourcen:
Wikipedia DNS-based Blackhole List
Zu URIBL_BLOCKED:
What does URIBL_BLOCKED mean? (Englisch)
SpamAssassin: URIBL_BLOCKED

DANE

TODO – auch dafür hatte ich bis jetzt leider keine Zeit )-:
See: https://de.ssl-tools.net/dane

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Untenstehende Gleichung bitte lösen * Zeit abgelaufen. Bitte das CAPTCHA nochmal laden.