DMARC und damit verbundene Probleme

Zusammenfassung

Das Mail-Policy-Protokoll DMARC wird für immer mehr Maildomains aktiviert. So hatte z.B. Google angekündigt, im Laufe des Juni 2016 seine Mailpolicy für die Domain gmail.com zu ändern. Allerdings wurde diese Änderung bisher (Stand Februar 2021) doch nicht umgesetzt. Anscheinend sind die damit einhergehenden Probleme selbst Google zuviel. Damit auch in Zukunft alle regulären E-Mails beim Empfänger ankommen, müssen an einige Stellen Änderungen sowohl im Mailsystem als auch bei bestimmten Softwareprodukten vorgenommen werden. Dies betrifft sowohl die Konfiguration als auch die Softwarekomponenten selbst.

Dieser Artikel beschreibt die momentan bekannten Probleme, die durch die Einführung von DMARC auftreten, und schlägt erste Lösungsmöglichkeiten vor. Sobald neue Erkenntnisse vorliegen, werden wir den Artikel aktualisieren. Der folgende Personenkreis sollte sich mit dem Inhalt dieses Artikels vertraut machen.

  • Administratoren von Software-Paketen (z.B. Web-Formulare oder Web-Applikationen), die auch E-Mails versenden
  • Betreiber von Mailinglisten-Servern
  • Administratoren von Mailinglisten
  • Betreiber von Groupware-Servern wie Microsoft Exchange, Novell Groupwise oder IBM Lotus Domino
  • Administratoren und Nutzer von Microsoft Exchange-Verteilern
  • Personen, die eine Weiterleitung auf einem Groupware-Server eingerichtet haben
  • Personen, die eine Weiterleitung auf einem Unix-System per Script, wie z.B. Sieve eingerichtet haben
  • Jeder der eine Mailadresse als Absender verwendet für die eine DMARC-Policy definiert wurde, wie z.B. gmail.com

Einführung

Google hatte angekündigt, seine DMARC-Policy für die Maildomain gmail.com im Juni 2016 vom Beobachtungs-Modus (Policy=NONE) auf den Ablehnungs-Modus (Policy=REJECT) umzustellen. Das bedeutet, dass alle E-Mailserver, die eine E-Mail mit einer Absenderadresse der Domain gmail.com entgegennehmen sollen, diese ablehnen dürfen und sogar ablehnen sollen, wenn die E-Mail nicht mit einem von Google ausgestellten Echtheits-Zertifikat (eine sogenannte DKIM-Signatur) versiegelt ist.

Das DMARC-Protokoll (Domain-based Message Authentication, Reporting & Conformance) wurde von den großen amerikanischen Freemail-Providern erarbeitet, nachdem sie unter massiven Phishing-Angriffen litten, bei denen ihre Maildomains missbraucht wurden. Während Yahoo und AOL bereits im April 2014 die REJECT-Policy in den Produktionsbetrieb übernahmen und durch die damit verursachten Probleme bereits für einen großen Wirbel in der Mailwelt sorgten, sah es in den vergangen zwei Jahren so aus, als ob DMARC eine Totgeburt wäre. In der Arbeitsgruppe, die aus DMARC einen IETF-Standard erstellen soll, kam es zu endlosen Wortgefechten zwischen den Anhängern und den Gegnern des DMARC-Protokolls. Nachdem Google als ein absolutes Schwergewicht im Mailprovider-Bereich jetzt ebenfalls die DMARC-Policy für seine Hauptmaildomain gmail.com scharfschalten will, ist damit wohl der Durchbruch gelungen. Viele Domaininhaber werden dem Beispiel Googles folgen und ihre Domain mit Hilfe von DMARC schützen. So wird in naher Zukunft auch für alle am LRZ gehosteten Maildomains eine DMARC-Policy publiziert werden.

Neben den positiven Auswirkungen einer DMARC-Reject-Policy gibt es aber auch zwei Problembereiche, die dafür sorgen, dass bei bestimmten regulären E-Mails nicht mehr sicher ist, ob sie beim Empfänger ankommen werden. Diese Problematik gilt nicht nur für die Domain gmail.com, sondern für alle Domains, die eine DMARC-Reject-Policy zum Schutz ihrer Domain publizieren.



Problembereich "keine DKIM-Signatur"

Damit eine E-Mail mit einer DKIM-Signatur versehen werden kann, muss sie über einen für die Domain zuständigen Mailserver verschickt werden. Ist das nicht der Fall, so kann die E-Mail kein gültiges Siegel haben und es liegt in der Hand des empfangenden Mailservers, ob er sie trotzdem entgegennimmt.

Nutzung des eigenen Mailservers

Benutzen Sie nicht ein Webmail-System, das automatisch den richtigen Mailserver auswählt, sondern einen eigenständigen Mailclient wie Outlook, Thunderbird oder K9, so müssen Sie daher Ihren Mailclient so konfigurieren, dass er den für die Absenderdomain zuständigen Mailserver zum Versenden nutzt. Sie dürfen nicht über einen anderen Mailserver verschicken, z.B. über einen Lehrstuhl-Mailserver im MWN, auch wenn dieser E-Mails mit fremden Absenderdomains akzeptieren würde.

(Web-)Formulare und Applikationen

Das eigentliche Problem sind aber nicht die Mailclients, die sich leicht umkonfigurieren lassen, sondern Softwarekomponenten, insbesondere Webformulare und -applikationen, die E-Mails versenden. In vielen Fällen sind diese so programmiert, dass sie als Absender die Mailadresse des Nutzers verwenden. Zum Beispiel das Online-Angebot von www.heise.de, bei dem man Meldungen des News-Tickers per E-Mail verschicken kann, oder Web-Applikationen, bei denen man sich zu einer Konferenz anmeldet oder über die man einen Lizenzschlüssel bezieht.

Diese Formulare und Applikationen müssen so umprogrammiert werden, dass sie

  • zum einen als Absender eine Mailadresse mit der Domain des eigenen Mailservers verwenden und
  • zum anderen ihre E-Mails authentifiziert (Benutzernummer + Passwort) über den eigenen Mailserver verschicken, damit die E-Mails ein Siegel für die Absenderdomain bekommen.

Ist bei komplexen Web-Applikationen (meist Mehrbenutzer-Systeme), wie z.B. Moodle oder ein Campus-Management-System, der authentifizierte Versand nicht möglich, so muss in solchen Fällen eine individuelle Lösung der Anbindung an den Mailserver gefunden werden.



Problembereich "zerstörte DKIM-Signatur"

Hat eine E-Mail ursprünglich ein Siegel, so kann es passieren, dass das Siegel auf dem Weg durch das Mail-Transport-System zerstört wird. Es ist dann für den empfangenden Mailserver nicht mehr feststellbar, ob es sich um ein zerstörtes aber früher gültiges Siegel oder um ein gefälschtes Siegel handelt. Dies geschieht meistens bei indirektem Mailfluss, d.h. wenn die E-Mail nicht direkt vom Mailserver des Senders zum Mailserver des Empfängers gelangt, sondern über einen dritten Mailserver geschickt wird. Hier sind zwei Fälle von Bedeutung, Weiterleitungen und Mailinglisten.

Weiterleitungen

Reguläre Weiterleitungen (Forward) machen keine Probleme, da bei diesen nur die Empfangsadresse im Umschlag der E-Mail ausgetauscht wird. Es gibt aber auch Weiterleitungen, bei denen die E-Mail verändert wird. Dies ist z.B. bei den drei großen Groupware-Systemen Microsoft Exchange, Novell GroupWise und IBM Lotus Domino der Fall, aber teilweise auch bei Weiterleitungen per Script, wie z.B. Sieve. Betroffen davon sind im MWN mehr als 20 Mailserver. Sofern es Patches der Hersteller für ihr Produkt gibt, müssen diese installiert werden, damit die DKIM-Signaturen nicht mehr zerstört werden. Nutzern des LRZ-Exchange-Systems empfehlen wir grundsätzlich, nicht die per Outlook bzw. OWA konfigurierbaren Exchange-internen Weiterleitungen zu verwenden, sondern Weiterleitungen im LRZ-Id-Portal bzw. in TUMonline vorzunehmen. Bei diesen Weiterleitungen bleibt eine DKIM-Signatur erhalten.

Mailinglisten

Mailinglisten, die eine E-Mail nicht verändern, machen keine Probleme. Oft ist eine Liste aber so konfiguriert, dass im Subject der Name der Liste eingefügt oder dass an die E-Mail ein "Footer" angehängt wird, in dem eine Anleitung zum Verlassen der Mailingliste enthalten ist. Bei solchen Listen wird die DKIM-Signatur zerstört, was fatale Auswirkung hat.

Die meisten Mailinglisten haben ein automatisches "Bounce-Handling", d.h. ist ein Empfänger mehrfach nicht erreichbar, so wird er aus der Mailingliste entfernt oder deaktiviert. Unterstützt der Mailserver des Empfängers DMARC, so wird er eine E-Mail mit zerstörter DKIM-Signatur in der Regel ablehnen und in der Folge wird der Empfänger aus der Liste entfernt/deaktiviert.

Als Abhilfe kann man entweder die Veränderung der E-Mails ausschalten oder Umgehungsmaßnahmen einschalten, sofern die Mailinglisten-Software so etwas anbietet. In Mailman Version 2.1.18, die am LRZ in Kürze installiert wird, sind folgende Umgehungsmaßnahmen vorgesehen falls für die Domain des Absenders eine Reject-DMARC-Policy publiziert wurde:

  • Reject: E-Mails werden abgelehnt und somit nicht über die Liste verschickt. So eine Policy wurde von etlichen Administratoren als Reaktion auf die DMARC-Policy von Yahoo und AOL angewendet, macht aber – nachdem immer mehr Domains eine DMARC-Policy publizieren – nur noch wenig Sinn.
  • Wrap Message: Die Orginalmail wird als Anhang einer neuen E-Mail verschickt. Die neue E-Mail hat als Absender eine Adresse mit der Domain der Liste und fällt damit nicht mehr unter die DMARC-Policy. Der ursprüngliche Absender wird in das Reply-To-Feld geschrieben. Die meisten Mailclients können mit solchen E-Mails nicht gut umgehen, z.B. auf solche E-Mails antworten. In der Praxis wird diese Option daher selten genutzt.
  • Munge From: Ähnlich wie "Wrap Message", die ursprüngliche E-Mail bleibt aber erhalten und es werden nur die Adressen geändert. Diese Umgehungsmaßnahme wird am häufigsten von den verschiedenen Mailinglisten-Produkten angeboten.

Unter die Mailinglisten fallen auch die Verteiler von Microsoft Exchange. Diese zerstören nach unserer Erfahrung ebenfalls DKIM-Signaturen, obwohl auf dem Exchange-Server des LRZ alle existierenden Patches eingefahren sind. Es gibt daher zurzeit für diesen Fall keine allgemein gültige Abhilfemaßnahme. Zu Problemen mit Verteilern kommt es nur dann, wenn eine E-Mail mit einer externen Absenderdomain an den Verteiler geschickt wird und ein Mitglied des Verteilers seine E-Mails nach extern weiterleitet.

Annahme von E-Mails trotz ungültiger DKIM-Signatur

Selbst wenn eine E-Mail keine Signatur trägt oder die Signatur zerstört wurde, kann es sein, dass die E-Mail vom empfangenden Mailserver angenommen wird. Das kann z.B. daran liegen, dass der Mailserver die DMARC-Policy nicht überprüft oder die Information nur in die Bewertung, ob die E-Mail als Spam markiert werden soll, einfließt. Wenn ein Mailserver weiß, dass die Quelle einer E-Mail vertrauenswürdig ist, so kann er trotz ungültiger Signatur deren DMARC-Policy ignorieren. Große Mailprovider haben durch die große Anzahl an E-Mails von verschiedensten Quellen die Möglichkeit einem Mailserver einen Wert auf einer Reputationsskala zuzuordnen anhand dessen sie dann über die Annahme von E-Mails von diesem Mailserver entscheiden können. Bei kleineren Mailservern ist in der Regel das Mailvolumen zu klein, sodass diese oft keine lokale Policy zur Überschreibung der DMARC-Policy haben.