E-Mail Schutz mit Plesk Obsidian für Linux

Update Februar 2024: Jetzt gehen Google und Yahoo dazu über, DMARC zu verlangen. Angeblich nur bei Sendern mit kommerziellem Volumen. Aber besser gleich mitmachen als später die böse Überraschung.

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, hier ganz knapp, und schließlich hier definitiv: RFC 6376. 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!
    • DNS-Record prüfen (mit Linux-Befehl):
      dig -t txt default._domainkey.{yourdomain.tld}
    • DNS-Record validieren (online; nur den Selektor “default” und die Domain eingeben):
      https://www.dmarcanalyzer.com/de/dkim-de/dkim-record-check/
    • DKIM-Subdomain für eine Subdomain: Falls E-Mails von einer Subdomain gesendet werden, z.B. von cron “root@mail.meinserver.de”, dann bedarf es auch einen eigenen Eintrag im DNS hierfür, der DKIM-Subdomain würde im obigen Beispiel
      default._domainkey.mail lauten.
    • 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.
    • Zur Klarstellung: Die Datei mit dem Namen “default” ist der Private Key. Der openssl Befehl erzeugt daraus den Public Key. Wer z.B. mit PHPMailer DKIM-Signierung selber programmieren will, kann die Key-Datei dafür einsetzen.

Formell sollte man auch ein DKIM Policy Record im DNS veröffentlichen, der besagt wie Empfänger bezüglich DKIM mit E-Mails von dieser Domain umgehen sollen. In der Praxis scheint es keine Probleme zu machen wenn er fehlt. Anyway:

_domainkey.your-from.tld   TXT   o=~; t=y; r=postmaster@your-from.tld

  • o=~; (Outbound Signing policy: “-” die Domain signiert alle E-Mails, “~” ist Standardwert und bedeutet dass die Domain manche E-Mails signieren könnte)
  • t=y; (Testmodus: “y” bedeutet dass die Domain gerade DomainKeys testet, daher sollen nicht-signierten und nicht-verifizierbaren E-Mails nicht nachteilig behandelt werden)
  • r=postmaster@your-from.tld (Responsible or Reporting E-Mail Adresse für Feedback bzgl. ungültiger Signaturen – ich vermute dass dies in der Praxis kaum beachtet wird, war eher in den Anfangstagen von DKIM wichtig)

DNS-Record prüfen (mit Linux-Befehl):
dig -t txt _domainkey.{yourdomain.tld}

DKIM testen

Abschließend sollten Sie unbedingt die DKIM-Einrichtung testen: Das geht recht übersichtlich Online mit dem DKIM Record Checker. Ansonsten: 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)
  • i=you@your-from.tld; (Die Identität des sendenden Benutzers bzw. Agenten. Eine E-Mail Adresse mit gleicher Domain vom d= Tag)
  • bh=… (body hash – der Signaturwert für den Rumpf der E-Mail)
  • b=… (der Signaturwert für die ganze E-Mail – Headers + Body)

Ausführliche Info zu den Tags gibt es hier und hier.

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:

  • Authentication-Results: mail.reeves.space;
    dkim=pass header.d=timreeves.de;
    spf=pass (sender IP is 178.238.234.182) smtp.mailfrom=info@timreeves.de smtp.helo=timreeves.de
  • Authentication-Results: mx.google.com;
    dkim=pass header.i=@timreeves.de header.s=default header.b=Zqvpgmzw;
    spf=pass (google.com: domain of info@timreeves.de designates 178.238.234.182 as permitted sender) smtp.mailfrom=info@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).

Für Thunderbird gibt es ein Add-on DKIM Verifier, das die DKIM-Signatur eintreffender E-Mails überprüft. Wichtig: In den Einstellungen des Add-ons (Extras | Add-on-Einstellungen | DKIM Verifier | Erweitert) Häkchen entfernen bei: Das Lesen des Authentication-Results header ersetzt die Add-on eigene Verifikation. Ansonsten nimmt das Add-on keine eigene Verifizierung vor, wenn der Server dies schon gemacht hat. Das Plugin zeigt das Prüfungsergebnis hier:
Thunderbird DKIM Verfier

CAVEAT: Wenn Sie in Plesk für eine Domain eine bestehende DKIM-Signierung deaktivieren und wieder aktivieren, so erzeugt Plesk einen NEUEN privaten Schlüssel – ein früherer DNS-Eintrag für DKIM wird damit ungültig!

CAVEAT: Wer DKIM auch mit PHPMailer an einem mit Plesk verwalteten Server verwenden will, soll hierfür eigene Keys erzeugen! Ich habe einen fruchtlosen Tag mit PHPMailer und den von Plesk erzeugten Keys verbracht – es war nicht zum Funktionieren zu bringen. Mit dem Schlüsselpaar (2048 statt 1024 Bits) die von diesem PHP-Code erzeugt wird, hat es dann auf Anhieb funktioniert. Außer mit Anhängen, hier gibt es wohl unterschiedliche Auslegungen davon, wie mit White Space umzugehen ist beim Erzeugen des Hash-Werts. Mehr zu diesen Themen hier und hier und hier.

WISSENSWERT: Wenn der Empfänger einer nicht-signierten E-Mail eine Weiterleitung hat (z.B. support@timreeves.de => info@timreeves.de), so fügt Postfix bei der Weiterleitung eine DKIM-Signatur hinzu, damit es beim Empfänger “keine Probleme” gibt. Die Signatur ist allerdings zweitklassig, weil sie nicht von der Domain des Absenders aus geschieht – aber besser als gar keine Signatur.

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.

Wie SPF-Records aufgebaut werden müssen, steht in den verlinkten Resourcen. Hier kann man in DNS hinterlegten SPF-Records online prüfen lassen. Der SPF-Record für meine eigene Domain timreeves.de sieht etwa so aus:

v=spf1 ip4:178.238.234.182 ip6:2a02:c205:3004:113::1 a mx -all

An dieser Stelle zwei Tipps wie man Fehler vermeidet:

  • Es dürfen keine Leerschritte nach den “:” stehen, sonst ist der Record ungültig!
  • Ein String-Wert in TXT Records darf nicht länger sein als 255 Zeichen. Falls ein SPF-Record sehr viele Möglichkeiten umfassen muss und daher die Länge 255 Zeichen übersteigt, muss der Wert in mehreren Teilen gesplittet werden, die jeweils in Anführungszeichen zu eigenen Strings gemacht werden:
    “v=spf1…” ” a a:reeves.one…”
    Achtung, trennende Leerzeichen müssen sich auch innerhalb der Anführungszeichen befinden, so dass im zusammengefügten Record-Wert nicht zwei Elemente ohne Trennung da stehen.

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:
Wenn Sie Maildienste von nicht eingetragenen Mailservern nutzen, liefert die SPF-Prüfung ein negatives Ergebnis. Dies ist häufig bei Mailinglisten der Fall, welche E-Mails in Ihrem Namen versenden und weiterleiten. Bei Problemen müssen Sie hier die entsprechenden Adressbereiche hinzufügen oder ggf. komplett auf die Verwendung von SPF verzichten. Weiterhin ist die Eintragung fester IP-Adressen mit Vorsicht zu genießen, da es z.B. im Falle von Serverumzügen zu ungültigen Einträgen kommen kann. Es empfiehlt sich daher generell die Einstellung der A- bzw. MX-Records zu setzen, da hierbei der SPF-Record immer aktuell bleibt.

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. Diese Einstellung nutzen wenn es zu Timeout-Problemen mit Plesk Milter kommt (der Empfänger erhält Abweisungen mit dem Code 451 4.7.1 Service unavailable).
    • Vier weitere 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 müsste 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

Zunächst Infos im Netz zu DMARC: Auf Englisch hier und hier, auf Deutsch in Wikipedia, schließlich die Plesk-Dokumentation zu DMARC. Auf’s Wesentliche reduziert: Ein DNS-Eintrag für eine Domain (TXT Record) teilt mit, ob die Domain DKIM und SPF benutzt, und als Richtlinie wie die Ergebnisse deren Auswertungen zu gewichten sind. Ferner an wen forensische und aggregierte Berichte zu senden sind (falls gewünscht, muss eine Adresse auf der gleichen Domain sein).

Die Einstellung in Plesk – “Tools & Einstellungen | Mailserver-Einstellungen | Allgemeine Optionen | DMARC” betrifft nur die Prüfung aller eintreffenden E-Mails nach DMARC – soweit für die Domain des Absenders ein DNS-Eintrag für DMARC vorhanden ist. Diese Einstellung kann also ohne weiteres aktiviert werden.

Es gibt in Plesk keine Einstellung bzgl. DMARC für ausgehende E-Mails, weil auf Plesk-Seite hierfür nichts getan werden kann. Ausgehende E-Mails werden dort (evtl.) nach DMARC geprüft wo sie eintreffen. Dabei kommt es schlichtweg darauf an, ob für die Absender-Domain ein entsprechendes TXT-Record in DNS hinterlegt ist. Der Inhalt des Records ist gleich, egal ob Sie Ihre DNS-Einträge in Plesk oder extern pflegen:

  • Subdomain = _dmarc
  • Domain = Ihre Domain, z.B. “timreeves.de”
  • Der TXT-Eintrag besteht aus einer Aneinanderreihung von “name=wert” Elementen, durch Semikola getrennt. Eine recht übersichtliche Liste der möglichen Elemente und Werte findet man hier.

Mit DMARC kann man allerdings leicht ein Eigentor schießen, in dem man (unbeabsichtigt) Empfänger anweist, Mails abzulehnen die von einem selbst stammen. Dies kann z.B. bei Weiterleitungen und Mailinglisten leicht zustande kommen. Daher empfiehlt es sich, wie bei LinkedIn sehr anschaulich erklärt, erst im Überwachungsmodus anzufangen (die nur täglichen Reports veranlasst “was wir getan hätten”), und diese Reports zu studieren, wo E-Mails fälschlicherweise abgelehnt werden würden. Wenn es zu viele sind, muss man individuell seine Strategie anpassen. Erst wenn alles rund läuft, schaltet man sozusagen scharf, geht in den Ablehnungsmodus.

Ein TXT-Anteil für den Überwachungsmodus sieht so aus (wobei v = Version, p = Policy – was zu tun ist, rua = report url aggregated – Empfänger der täglichen Berichte):

v=DMARC1; p=none; rua=mailto:dmarcreports@example.com

Wenn Sie von den Überwachungsmodus in einen aktiven Modus wechseln, haben Sie zwei verschiedene Modi zur Auswahl (anstelle der “none”):

  • quarantine: Ungültige Nachrichten als Spam markieren und sie an den Spam-Ordner des Empfängers senden. Die Empfänger können Spam-Nachrichten überprüfen, um legitime Nachrichten zu identifizieren.
  • reject: Die Nachricht ablehnen. Bei dieser Option sendet der empfangende Server normalerweise eine Bounce-Nachricht an den sendenden Server.

Achtung mailto-Adresse auf anderer Domain: Falls rua=mailto: eine Email-Adresse bei einer anderen Domain als die zu-schützende Domain spezifiziert, so muss diese andere Domain den Empfang von DMARC-Reports explizit mit einem TXT-Record erlauben. Entweder spezifisch pro Schutzdomain, oder per Wildcard:
Name: *._report._dmarc  Wert: v=DMARC1

Achtung  Mailinglisten: Wer seine Mailinglisten nicht selber versendet (z.B. mit MailPoet für WordPress), sondern von einem Dienstleister (wie MailChimp) verschicken lässt, hat ein Problem mit DKIM, weil der Dienstleister die E-Mails nicht mit dem DKIM des Kunden signieren kann (denn nur der Kunde hat das Private Key für seine eigene Domain). So wird es schwierig dass der “richtige” From: Header (me@mydomain.eu) benutzt werden kann. Mehr zu diesem Thema in den Wikipedia-Einträgen (de + en) zu DMARC. Jedenfalls ist sicher: Wenn DKIM ein Problem hat, hat auch DMARC ein Problem.

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 – hierfür hatte ich bis jetzt leider keine Zeit )-:
See: https://de.ssl-tools.net/dane

Off-Topic: SpamAssassin und NTLDs

NTLD = New Top Level Domain. Ich habe nicht schlecht gestaunt als ich beim Testen eine kurze E-Mail von meiner Domain “reeves.space” an mich selbst geschickt habe: Spampunkte für FROM_SUSPICIOUS_NTLD und FROM_SUSPICIOUS_NTLD_FP, ein Score von +1.5 trotz gültigem DKIM und SPF. Damit habe ich nicht gerechnet. Darauf hin habe ich The World’s Most Abused TLDs gefunden, sowie weitere Hinweise hier und hier. Das finde ich schade weil ich die neuen TLDs mag, nun gereicht es mir mitunter zum Nachteil )-:

  • de = 0.4% bad (score 0.02)
  • one = 1.3% bad (score 0.05)
  • space = 4.0% bad (score 0.27)
  • world = 18.9% bad (score 1.49)
  • work = 52.2% bad (score 5.25)

Ein Tipp zu Plesk Premium Antivirus (eigentlich Dr. Web): Hier die Plesk-Doku zu Antivirus, und hier mein Beitrag im Plesk-Forum wie man es zum Laufen bekommt 🙂

1 Kommentar

zu E-Mail Schutz mit Plesk Obsidian für Linux

Schreibe einen Kommentar

Bitte alle Felder ausfüllen. Deine IP-Adresse wird anonymisiert gespeichert. Fantasienamen und E-Mail Adressen (wie "donald@duck.org") werden akzeptiert.