Wie DKIM und SPF funktioniert (und weshalb Mail-Forwarding eine schlechte Idee ist)

Im folgenden sollen das Sender Policy Framework (SPF) sowie Domain Keys (DKIM) grob erläutert werden. Hierbei handelt es sich um keine Konfigurationsanleitung sondern eine Beschreibung, die für Benutzer die mit diesen Konzepten das erste Mal in Kontakt kommen, handeln. Eine Konfigurationanleitung wird eventuell später folgen.

Hierbei handelt es sich nur um eine kurze (schnell entstandene) Zusammenfassung.

Problem

Welches Problem versuchen SPF und DKIM zu lösen? E-Mail wird zwischen Mailservern über das simple mail transfer protocol übertragen. Dieses gibt vor, dass E-Mail über TCP Port 25 bzw. mit SSL/TLS über Port 465 übertragen wird. Desweiteren gibt es Port 587 (submission) der nur von Mail Clients genutzt wird und nicht für den Transfer zwischen Mailservern genutzt wird. Dieses Protokoll definiert einige wenige Kommandos die zwischen Mailservern bzw. Mail Client und Server genutzt werden können um Mails zu versenden.

Beim Versand zwischen Mailservern kommt prinzipiell nur eine Sequenz aus den Kommandos HELO, MAIL FROM:, RCPT TO:, DATA sowie QUIT zum Einsatz. Eine typische SMTP Session könnte zum Beispiel wie folgt aussehen:

> HELO sourceserver.example.com
< 250 OK
> MAIL FROM:sender@example.com
< 250 OK
> RCPT TO:receiver1@example.com
< 250 OK
> RCPT TO:receiver2@example.com
< 250 OK
> DATA
< 354 start mail input
> From: Visible Sender <whatever@example.com>
> To: Visible Receiver <another@example.com>
> Subject: Testmail
>
> Lorem ipsum dolor sit amet, consectetur
> adipisici elit, sed eiusmod tempor incidunt
> ut labore et dolore magna aliqua.
> .
< 250 OK
> QUIT
< 221 closing

Wie man hieraus erkennen kann handelt es sich um ein sehr simples Protokoll, wobei prinzipiell beliebige Werte für Absender und Empfänger sowie das eigentliche Mail (nach dem DATA Kommando) übergeben werden können.

Bei den Daten, die der Benutzer sieht, handelt es sich prinzipiell um die nach DATA angegebenen Felder im nach RFC 822 bzw. aktueller RFC 2822. Diese haben keinen Einfluss auf das Routing der Mails.

Als erste Prüfung - um Spam und gefälschte Absenderadressen einzudämmen - haben Mailserverbetreiber sehr früh damit begonnen die bei HELO übergebenen Namen in so fern zu überprüfen, als dass sie die reverse DNS Einträge der IP Adressen von denen aus die Verbindung erfolgte mit dem übergebenen Namen verglichen haben. Hat dieser nicht übereingestimmt, wurde die Verbindung verworfen. Hierdurch kann allerdings noch keine Absenderüberprüfung durchgeführt werden, da Mails oft viele Mailserver auf dem Weg von Sender zu Empfänger hinter sich lassen - und oft ein Mailserver für mehrere Domains zuständig ist.

Desweiteren wird gerne überprüft, ob es sich bei der verbindenden IP Adresse um eine bekannte dynamic range handelt - einer Adresse aus einer Liste von IP Bereichen die bekannter Weise zu Dialup-Internetanbietern gehören (ich persönlich bin mit dieser Überprüfung nicht sehr glücklich, da hierdurch IP Adressen eine bestimmte Verwendungsklasse zugewiesen wird und dies genauso wie die Idee einer Identifizeirbarkeit oder einer Geoinformation eines IP Adressbereichs grundsätzlich der Idee von IP Netzwerken widerspricht, in der IP Adressen beliebig annonciert und verwendet werden können). Hierdurch sollen primär Versender ausgeschlossen werden, die durch Schadsoftware infiziert und zur Spamverbreitung genutzt werden.

Darüber hinaus gab es keine Prüfung, ob der Absender berechtigt ist unter dem angegebenen Namen ein Mail zu versenden. Aus diesem Grund wurden die Mechanismen SPF und DKIM eingeführt

Sender policy framework

Bei einer Überprüfung nach dem sender policy framework fragt der empfangende Mailserver auf der bei DNS Zone, zu der in MAIL FROM: gehörigen Domain nach einem so genannten SPF TXT record. Dieser Record erlaubt dem Domainadministrator vorzugeben, welche Server unter dieser Domain Nachrichten versenden dürfen.

Ein solcher Record könnte wie folgt aussehen:

v=spf1 +mx +ip4:93.185.132.236 +ip6:2001:470:26:71c::1 +ip4:5.9.112.14 +ip6:2a01:4f8:162:5308::2 -all

In diesem Fall würde der Versand von Mail allen als MX eingetragenen Mailservern (i.e. die Server, die Mails für diese Domain empfangen und in der DNS Zone gelistet werden) sowie den zusätzlich gelisteten Servern gestatten. Kein weiterer Server ist berechtigt Mail zu versenden.

Wird Mail von einer anderen Quelle empfangen, wird dieses (meistens mit einer entsprechenden Fehlermeldung) verworfen.

Dies hat bereits beschränkt Einfluss auf Mail Forwarding, da die Absenderadressen hierbei nicht einfach weiterverwendet werden können. Der weiterleitende Server würde sonst die Absenderadresse fälschen, sich aber nicht auf der Liste der freigegebenen Server befinden. Aus diesem Grund würde der empfangende Mailserver das Mail ablehnen.

Wird Mail-Weiterleitung trotz SPF gewünscht muss das Sender Rewriting Scheme (SRS) verwendet werden um den Envelope Sender entsprechend anzupassen. Würde die Absenderadresse einfach nur ausgetauscht werden, würden eventuell Bounces nicht mehr korrekt an den ursprünglichen Absender zugestellt werden (diese werden immer nur an den Envelope Sender zugestellt, niemals an den im Mail Header gelisteten Absender). Um SRS einzusetzen wird in der modifizierten Absenderadresse eine zusätzliche Authentifizierungsmethode eingesetzt - hierzu müssen aber alle weiterleitenden Mailserver SRS korrekt implementieren, was gerade bei beliebten großen Mailanbietern natürlich nicht der Fall ist.

Domain Keys Identified Mail (DKIM)

SPF schützt nur den Envelope Sender, prüft also nur ob die unter MAIL FROM: angegebene Adresse berechtigt ist von dem gegebenen Server zu versenden. Dies bietet keinen Schutz vor beliebigen Einträgen im eigentlichen Mail Header (d.h. den Feldern, die der Nutzer sieht). Aus diesem Grund wurde DKIM eingeführt. Dieses arbeitet unabhängig von SMTP bzw. dem Envelop. Mails wird ein zusätzlicher Header (wie die obigen From:, To: und Subject: Zeilen) hinzugefügt, der eine komplette Signatur des Mails beinhaltet. Der dazugehörige private Schlüssel ist nur dem ursprünglichen authorisierten versendenden Mailserver bekannt, der öffentliche Schlüssel wird wiederum in der DNS Zone untergebracht.

Der Schlüssel in der DNS Zone findet sich wiederum in einem TXT record:

default._domainkey              IN TXT                  ( "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDKr3sURaMkIL2...." )

Die Signatur des Mails kann wie folgt aussehen:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mail.tspi.at;
	s=default; t=1555119871;
	bh=qcZP0zz6LExj5BywHZZuZO+SQK/dVhsNWEsVtBr8sn8=;
	h=To:Subject:Date:From;
	b=Jo4iXvv20PQsqScGjUqaa2sGkhNq7pAhBnnxmEFO8A/Gud5pZDizV2d4LacLuZ2LT
	 SDC/QVmKZMf4zJ6gJiqxsIE3GIoHKtsNTRQbR44nkN3pVH7oKbznc3D9dKYyA+LAyM
	 zBE7kKjYELKzx55I4cIVg9RBr70UuMNWon3OsJy8=

Diese Signatur kann nur mit Hilfe des zum öffentlichen Schlüssel gehörigen privaten Schlüssel vorgenommen werden. Der empfangende Mailserver prüft nun, ob diese im eigentlichen Mailkörper vorkommende Signatur zur im From: gelisteten Absenderdomain gehört. Ist dies nicht der Fall, wird das Mail verworfen.

Diese Signaturen bereiten zwar keine Probleme bei Mail Forwards - aber eventuell bei Mailinglisten oder anderer Software wie Virenscanner oder Lösungen die unwirksame Disclaimer an ausgehende Mails anhängen, sofern diese die E-Mails umschreiben (z.B. um die Absenderadresse zu verschleiern). In diesem Fall muss eine Mailingliste ihre eigene Adresse als From: angeben und das Mail erneut signieren. Der ursprüngliche Absender kann von der Mailingliste in reply-to gelistet werden um Antworten an den Absender anstatt an die Adresse zu bedingen.

Domain based message authentication, reporting and conformance (DMARC)

Domain-based Message Authentication, Reporting and Conformance bietet eine Möglichkeit zu konfigurieren, wie mit Mails verfahren werden soll, die gegen die von SPF oder DKIM vorgegebenen Regeln verstoßen. Hierzu wird ebenfalls ein DNS Record in der DNS Zone eingetragen, der das gewünschte Verhalten beschreibt:

"v=DMARC1;p=reject;sp=reject;pct=100;ruf=mailto:postmaster@example.at;adkim=r;aspf=r"

Der hier dargestellte Record fordert den Empfänger dazu auf, Mails die gegen die Policies verstoßen zu 100 Prozent zu verwerfen und gesammelte Reports an die angegebene postmaster Adresse zu senden. Dieser Record erlaubt es zu Testzwecken das Filtern zu reduzieren oder komplett zu deaktivieren, sofern sich der Empfänger daran hält

Ein Mail wird nach DMARC dann akzeptiert, wenn mindestens eines der Authentifizierungsverfahren SPF oder DKIM ein positives Ergebnis liefert. Wird also ein korrekt DKIM signiertes Mail von einer falschen Absenderadresse zugestellt oder ist die DKIM Signatur falsch, der Absender allerdings nach SPF zum Mailversand berechtigt wird das Mail akzeptiert. Nur wenn beide Methoden fehlschlagen wird ein Mail verworfen.

Welche Software wird eingesetzt

• SPF: policyd-spf überprüft SPF Records beim Empfang
• DKIM: OpenDKIM bietet sowohl Verifizierung als auch Signierung beim Versand

Was für Forwards nötig ist

Entweder wird auf allen Mailservern, die mit den Mails in Kontakt kommen flächendeckend SRS eingesetzt - oder die empfangenden Mailserver müssen so konfiguriert werden, dass sie keine SPF Prüfung bei Mails, die von den vertrauenswürdigen Forward Servern stammen, durchführen.

Im allgemeinen sollte man versuchen Mail Forwarding außerhalb der eigenen Infrastruktur (z.b. Zwischen eigenen Border SMTP Mailservern sowie internen Servern - personen die solche Infrastruktur administrieren wissen allerdings über diese Mechanismen im Normalfall bescheid) vermeiden.

This article is tagged:

• E-Mail
• Internet
• Tutorial