Verteiler und SPF/DKIM/DMARC

Mailverteiler oder Mail-aktivierte Sicherheitsgruppen sind in Firmen eine elegante Möglichkeit, Nachrichten an eine Adresse zu senden und an alle Mitglieder verteilen zu lassen. Was intern problemlos funktioniert, kann mit externen Kontakten als Mitglied und insbesondere als Absender eine Herausforderung werden, denn Spamfilter können dabei stören.

Lesen Sie dazu auch die Seite Mailingliste mit DMARC, DKIM, SPF, ARC

Szenarien

Eine Verteilerliste in Exchange funktioniert derart, dass der Absender nicht verändert wird und nur die Zieladressen umgeschrieben werden. Entsprechend haben wir mehrere Teilnehmer:

  • Verteiler V
  • Interner Teilnehmer C / D
  • Externer Teilnehmer A / B

Die Teilnehmer können auch als Absender fungieren. Entsprechend haben wir die zwei Konstellationen, dass der Absender intern oder extern sein kann und der Empfänger auch Intern oder Extern.

Damit gibt es zwei mögliche Konstellationen:

  1. Absender A (extern) sendet an Verteiler V und wird an Empfänger D und B verteilt
    Dieser Fall ist interessant und wird im folgenden weiter beleuchtet, da hier bei Benutzer B eine Mail von Benutzer A ankommt, für dessen Domain die Firma 2 nicht autoritativ ist
  2. Absender C (intern) sendet an Verteiler V und wird an Empfänger D und B verteilt
    Der Fall ist nicht besonders, denn der Absender C ist in der Firma 2. Selbst wenn eine Mail über einen Verteiler in Firma 2 verteilt wird, ist die Firma 2 "autoritativ" und kann per SPF und DKIM korrekt den legitimen Versand nachweisen.

Diese Seite beschäftigt sich nur noch mit Fall 1 und den möglichen Problemen.

Vorbemerkungen

Ich beschreibe im nächsten Abschnitt die Probleme bei der Zustellung so einer Mail, wenn Absender und Empfänger eine "State of the Art"-Konfiguration hinsichtlich der Spamfilterung etabliert haben. Diese sind u.a.

  • SPF mit -All"
    Eine "gute" Firma beweist ihren legitimen Versand, indem Sie die Mails nur von Mailservern versendet, deren IP-Adressen  DNS-Eintrag per SPF veröffentlich sind und mit einem "-all" jeglichen anderen Servern den Versand verbietet. Das ist leider noch nicht bei allen Firmen so.
  • SPF-Check beim Empfang
    Ein gut konfigurierter Mailserver prüft beim Empfang, ob es für die Domain des Absenders einen SPF-Eintrag im DNS gibt und vergleicht die IP-Adresse des Absenders mit dem Eintrag
  • DKIM Signatur
    Reines SPF hat seine Beschränkungen, wenn Mails über Zwischenstationen laufen oder der Absender im SMTP-Protokoll und im Mail-Header unterschiedlich sind. Daher gehört es heute zum guten Ton, die essentiellen Felder einer Mail (Betreff, Absender, Empfänger, Body) mit einer DKIM-Signatur zu versehen und den passenden Schlüssel zur Prüfung per DNS zu veröffentlichen. Wenn ihr Mailserver kein DKIM kann, dann schauen Sie sich mal NoSpamProxy oder andere Relay-Systeme an, die ihre Mails auf dem Weg ins Internet signieren.
  • DKIM Prüfung
    Und natürlich sollte auch beim Empfang eine eventuell vorhandene DKIM-Signatur geprüft werden, um z.B. Veränderungen/Fälschungen der Mail zu erkennen oder SPF-Fehler zu ignorieren
  • DMARC-Policy
    Der Absender kann über eine DMARC-Policy zusätzlich dem Empfänger empfehlen, wie er die SPF/DKIM-Regeln auslegen soll und einen Report erbeten. Dazu muss der Empfänger natürlich DMARC unterstützen und die veröffentlichten Einstellungen umsetzen.
  • Exchange Verteiler und Mitglieder
    Wenn Sie so eine Lösung mit einem Exchange Verteiler aufbauen wollen, dann denken Sie bitte daran, dass ein Exchange Verteiler ein Active Directory Verteiler oder Gruppe ist und alle Mitglieder auch als MailContact-Objekte im Active Directory angelegt sein müssen. Nur wenn sie den Status "HideFromAddressbook:$true" haben, sind sie für ihre Anwender nicht in der GAL sichtbar.

Wenn sie noch nicht diese an sich wünschenswerte Konfiguration umgesetzt haben, dann kann es sein, dass Sie die Fehler noch nicht sehen. Das kann sich aber täglich ändern, insbesondere wenn externe Empfänger ihrerseits die Einstellungen strenger umstellen.

Teilstrecke 1: Maileingang

Zuerst betrachten wir die originale Mail, welche an den Verteiler zugestellt wird. Wie oben schon beschrieben, interessiert mit der Fall mit einem interner Absender C nicht weiter. Die Einlieferung durch den externen Benutzer A ist viel interessanter:

Für den Mailserver der Firma 2 ist die Nachricht erst einmal eine normal zugestellte Mail. Der Mailserver des Absenders sollte die Mail per DKIM signieren und über eine IP-Adresse einliefern, die per SPF veröffentlicht ist. Dann kann der "Check1" beim Empfänger zumindest den Absender verifizieren.

Als Betreiber des extern erreichbaren Verteilers sollten sie alles daransetzen, dass nur legitime Absender eine Mail an den Verteiler adressieren. Erst durch SPF und/oder DKIM können Sie aber sicherstellen, dass die SMTP-Adresse des Absenders von einem autorisierten Mailserver kommt.

Sie wollen doch nicht mit ihrem Verteiler als "Spamversender" negativ auffallen. Das bedeutet aber auch, dass:

  • Ihr Mailserver SPF und DKIM "streng" prüft
  • Die Verteilerliste zwar anonym aber nur für eingeschriebene Mailadressen erreichbar ist
  • Die Absender möglichst SPF/DKIM korrekt verwenden

Die beiden ersten Punkte können Sie als Betreiber selbst steuern aber wenn die Absender weder SPF noch DKIM machen, sollten das Gespräch suchen oder den Versand dieser Domains an die Verteilerliste nicht erlauben.

Teilstrecke 2 - Variante TO-Umschreibung

Nachdem die Mail durch den Verteiler verarbeitet wurde, wird sie an alle Mitglieder gesendet. Ein interner Empfänger D in der Firma 2 ist wieder unkritisch, da hier kein weitere Absender/Spam-Prüfung erfolgt. Auf dem Weg zu, Empfänger B wird es aber interessant:

Die Verteilerserver muss für die Zustellung an Empfänger A natürlich die Zieladresse umschreiben. Wenn er aber die Absenderadresse unverändert lässt, dann kann Empfänger sehen, wer aus der Verteilergruppe ihm diese Mail gesendet hat. Eine SMIME-Signatur von Absender A bleibt in dem Fall sogar erhalten aber es gibt zwei Probleme, die eine Zustellung sehr wahrscheinlich blockieren:

  • SPF Fail
    Wenn Firma 3 den SPF-Record von Absender A  der Firma 1 prüft, dann kann er feststellen, dass die IP-Adresse von Firma2 natürlich nicht für den Versand "als Firma 1" legitimiert ist. Wenn nur SPF geprüft wird, landet die Mail höchstwahrscheinlich im Spamfilter von Firma 2, d.h. Quarantäne, gelöscht oder schlimmstenfalls eine Unzustellbarkeit, die bei Benutzer A landet.
  • DKIM-Fail/OK
    Wenn die Mail noch mit der DKIM-Signatur von Absender A versehen ist, bleibt diese gültig wenn der DKIM-Umfang nicht den Empfänger einschließt. Ich habe aber schon DKIM-Signaturen (z.B. GMX.NET) gesehen, bei denen auch das "to"-Feld mit eingeschlossen war und das haben wir gerade geändert.

Diese Konstellation ist nicht sonderlich robust.

Teilstrecke 2 - Variante DKIM

Mit dem Einsatz von DKIM können Sie einen anderen Weg einschlagen. Sie können die "Envelope-TO"-Adresse ändern, anhand die Mail in das Zielpostfach zugestellt wird. Im Header der Mail werden aber der Absender und Empfänger nicht geändert:

Wenn der Absender A seine Mail per DKIM signiert hat, dann bleibt die DKIM-Signatur gültig, sofern nicht ein Disclaimer o.ä. den Inhalt der Mail verändert hat. Damit kann auch der Server der Firma3 die eingehende Mail prüfen. Der SPF-Check schlägt zwar fehlt aber der DKIM-Check ist gültig. Die Prüfung lautet in Kurzform:

(SPF=PASS or DKIM=PASS)
AND
(header-from and envelope-from is aligned or DKIM domain d= aligned with header-from).

Wenn also "DKIM=PASS" ist und zusätzlich die Domain im "D=" des DKIM-Headers mit dem Header-Fom übereinstimmt, dann kommt die Mail an. Das bedeutet aber, dass

  1. Absender DKIM verwenden muss
    Das machen zwar immer mehr Firmen aber auch in Office 365 ist es nicht "per Default" eingeschaltet, sondern muss von Administrator erst aktiviert werden.
  2. Der Empfänger DKIM auswertet
    Auch hier gibt es noch viele Mailserver, die DKIM ignorieren und dann muss auch hier der Administrator die Regeln festlegen.
  3. Kein Zwischensystem etwas an den Feldern ändern
    Das sollte nicht der Fall sein aber gerade Exchange Online versagt hier (Stand Feb 2022), da es das Feld X-MS-Exchange-SenderADCheck mit einbindet und beim "Durchleiten" auf "0" setzt und damit die originale DKIM-Signatur ungültig macht.

Es gibt hier leider zu viele "Wenns und Abers", als dass dies als Lösung bezeichnet werden könnte.

Teilstrecke 2 - Variante SRS

Um die Probleme von Umleitungen über andere Server zu "lösen", gibt es schon viele Jahre den "Sender Rewriting Scheme". Der Server n Firma 2 ändert zwar den Absender aber auf eine ganz bestimmte Weise.

SRS0=HHH=TT=hostname=local-part@domain

Dabei bedeuten HHH = Hashwert und TT = Timestamp. Aus dem Absender UserA@firma1.de wird dann folgendes

SRS0=HHH=TT=firma1.de=UserA@firma2.de

Der Trick dabei ist, dass beim Firma3 nun als "From"-Adresse die Domain von "Firma2" erscheint und der Mailserver von Firma3 entsprechend den SPF-Record von Firma2 abfragt. Wenn Firma2 einen korrekten SPF-Eintrag hinterlegt hat, wird diese Prüfung ein "SPF OK" liefern. Damit ist die Mail natürlich noch nicht zugestellt, denn weitere Spamfilter können immer noch was dagegen haben.

Teilstrecke 2 - Absender ändern

Wenn der Absender nicht weiter sichtbar sein muss, dann kann ich als Betreiber der Verteilerliste natürlich sowohl Empfänger als auch Absender ersetzen.

Mit dem Absender des Verteilers kann ich als Firma2 nun natürlich wieder einen eigenen gültigen SPF-Eintrag und DKIM nutzen, damit die Mails zuverlässiger zugestellt werden. Diese Lösung hat allerdings zwei "Probleme":

  • Empfänger B sieht den Verteiler als Absender
    Das ist oft nicht gewünscht, da sie so nicht direkt an der Mail erkennen können, welcher Teilnehmer die Mail tatsächlich gesendet hat.
  • Exchange unterstützt dies nicht
    Ich habe noch keinen Weg gefunden, wie ich in Exchange bei einem Verteiler die Änderung des Absenders auf dem Server einstellen kann.

ARC?

Das Problem mit den "umgeleiteten Mails", bei denen der Absender nicht verändert werden soll, betrifft nicht nur Mailinglisten und Verteiler sondern auch klassische Umleitungen bei Migrationen. Wenn Sie z.B. ihr Postfach von einem System zu einem anderen System umstellen wollen, dann ist es relativ einfach das neue Postfach mit einer Neuen Domain in Betrieb zu nehmen und selbst eine Übernahme der Domain per MX-Record ist einfach. Wenn aber eine von ihnen genutzte Domain bei der Quelle verbleibt, können Sie nur eine Umleitung einrichten oder die Inhalten irgendwie "synchronisieren". Im Ziel wollen Sie natürlich den richtigen Absender sehen. Damit treffen die gleichen Probleme wie beim Verteiler zu.

Daher haben Provider mit ARC - Authenticated Received Chain einen weiteren "Standard" etabliert. Der Provider kann die Mails mit seinem Siegel "im Auftrag" signieren und der Zielprovider vertraut der ARC-Signatur des anderen Providers. Klar, dass dazu die beiden Provider mitspielen müssen und sich auch vertrauen.

Selbst wenn Sie in ihrer eigenen Firma ein ARC-Siegel anbringen, sollten Sie nicht davon ausgehen, dass alle möglichen Empfänger ihres Verteilers schon mit ARC-Signaturen umgehen können und dann ihrem System pauschal vertrauen. Sie könnten dann nämlich mit jeder beliebigen Absenderadresse auch unerwünschte Mails an die Firmen senden die ihnen vertrauen.

Umleitung mit Posteingangsregel

Ich kann natürlich die Mail an ein Postfach zustellen und dort mit Posteingangsregeln eine "Weiterleitung" statt der Umleitung konfigurieren. Allerdings muss die Regel ja vom Server ausgeführt werden, so dass "individuelle Kontakte" oder "Kontakt-Verteiler" in diesem Postfach nicht genutzt werden können. Für eine Client-Regel müsste aber irgendwo ein Outlook laufen.

Natürlich könnten Sie auch ein Skript bauen, welches per EWS die eingehenden Mails im Postfach empfängt und an die Abonnementen weiter verteilt. Dann kommt aber schnell der Wunsch dazu, dass sich Nutzer selbst ein- und austragen können und ehe sie es sich versehen, sind sie beim ausgewachsenen Listserver oder einer Newsletter-Lösung, die gleich auch Double-OptIn, Throttling u.a. enthält.

Ergebnis

Exchange Verteiler sind aus meiner Sicht eine Option, Mails an eine Funktionsadresse an mehrere Postfächer in der gleichen Organisation zu verteilen aber bitte nicht an externe Empfänger. Ich möchte dazu nicht fremde Kontakte in meinem Active Directory anlegen, damit diese von eine Exchange-Verteiler erreicht werden können.

Die Mail nach Extern wäre technisch noch machbar aber nur, solange die Absender in meiner Exchange Organisation sind und sich entsprechend authentifizieren. Ein aus dem Internet quasi "anonym" erreichbarer Verteiler hat ein sehr hohes Schadensrisiko, wenn Sie nicht alle Hebel in Bewegung setzen, um die Gültigkeit der Absenderadresse abzusichern. Und selbst wenn sie nur Mails von legitimen Absendern annehmen, funktioniert das nur mit rein internen Empfängern gut. Ein Versand extern eingelieferter Mails an ebenfalls externe Empfänger ist mit Bordmitteln nur möglich, wenn die Spamfilter nicht zu streng hinschauen. Darauf würde ich mich lieber nicht verlassen.

Weiterhin ist die Gefahr sehr hoch, dass die Infrastruktur, die einen Verteiler betreibt, mit seinen IP-Adressen sehr schnell auf vielen IP-Blocklisten landet, weil die Empfängerserver ihn "melden" und damit die Zustellqualität stark beeinträchtigt wird. Über kurz oder lang werden auch Spammer die Mailadresse des Verteilers erfahren und beaufschlagen. Sei es von extern, so dass sie ohne SPF/DKIM-Prüfung und entsprechende Konfiguration durch die legitimen Absender den Service einstellen müssen oder von Intern durch Trojaner (Emotet und Co), die als authentifizierter Benutzer senden können.

Generell sollten Sie natürlich überlegen, ob eine "Duplikation" von Inhalten an mehrere Empfänger samt "Kettenbriefen" heute im Zeichen von Teams Chats noch zeitgemäß sind.

Wenn Sie dennoch eine Verteilung von Informationen von und an externe Teilnehmer per Mail umsetzen wollen, dann sollten Sie dies nicht mit Exchange Bordmitteln machen, sondern sich einen passenden List-Server suchen.

Weitere Links