SPAM-Schutz: Überprüfung des Absenders

30.09.2023 | 11:00 Uhr

Jeden Tag erreichen uns tausende von Nachrichten, die die Empfänger gar nicht haben wollen. SPAM oder gar Mails mit Trojanern. Gerne werden dabei die Absenderadressen gefälscht. Mails von info@a.mazon.de oder ebay@ebey.de, die hier in den vergangenen Tagen aufgetaucht sind, sind für den Benutzer vielleicht noch zu erkennen.

SPF

Doch was ist, wenn die Mail von order@ebay.de kommt? Vertrauen Sie diesem Absender? Mit großer Sicherheit! Öffnen Sie die beigefügte Bestellbestätigung im PDF-Format? Aber klar!

Das Problem: Diese Mails sind nicht echt, nicht authentisch. Das PDF-Dokument enthält einen kleinen Trojaner, der Sicherheitslücken in PDF-Betrachtungsprogrammen ausnutzt.

Ein Erkennen solch gefälschter Nachrichten ist aber möglich:

Sender Policy Framework (SPF)

Dazu muss der Inhaber einer Domain im DNS festlegen, welche Mail-Server offiziell die Domain in der Absenderadresse nutzen dürfen.

Der empfangende Mailserver prüft vor der Annahme einer E-Mail, ob der absendende Server autorisiert ist, diese Nachricht zu verschicken. Ist der Name oder die IP-Adresse nicht in der Liste der zugelassenen Systeme zu finden, wird der Empfang abgelehnt.

Viele führende Provider nutzen dieses Verfahren: Outlook.com/Hotmail (Microsoft), GMail (Google), icloud.com (Apple) oder GMX/web.de (1&1) haben im DNS die zulässigen Postausgangsserver definiert.

Schwarze Schafe

Leider nutzen aber nicht alle Domaininhaber dieses recht einfache Verfahren zum Schutz ihrer Identität. Oder sie definieren, dass der empfangende Mailserver falsche Nachrichten nicht ablehnen muss. Ist keine feste Ablehnung für falsche Systeme definiert, hängt es vom Mailserver ab, wie er den Absenderserver bewertet und die Mail ggf. als SPAM markiert.

Daher sollten Sie beim Empfang von Mails mit folgenden, beispielhaften Domains, von denen wir in den vergangenen Wochen SPAM erkannt haben, etwas genauer hinsehen:

t-online.de | kein Postausgangsserver per SPF definiert
telekom.de | kein Postausgangsserver per SPF definiert
bundesregierung.de | kein Postausgangsserver per SPF definiert
niedersachsen.de | kein Postausgangsserver per SPF definiert
oldenburg.de | kein Postausgangsserver per SPF definiert
brake.de | kein Postausgangsserver per SPF definiert
ebay.de/ebay.com | Ablehnung kein Muss
dpd.de/dpd.com | Ablehnung kein Muss
otto.de | Ablehnung kein Muss
lufthansa.de | kein Postausgangsserver per SPF definiert (für lufthansa.com schon, Ablehnung aber kein Muss)
gruene.de | kein Postausgangsserver per SPF definiert
spd.de | Ablehnung kein Muss
fdp.de | Ablehnung kein Muss

Darüber hinaus gibt es ein weiteres Verfahren, um die Authentizität des Absenders noch besser festzustellen:

DKIM (DomainKeys Identified Mail)

Bei diesem Verfahren werden die Nachrichten mit einem digitalen Schlüssel signiert. Die öffentliche Kopie wird im ebenfalls DNS hinterlegt und kann so von den Empfängerservern überprüft werden. Damit lässt sich feststellen, ob der Absender auch wirklich authentisch ist. Zudem kann der Domaininhaber definieren, was im Fall von falschen Signaturen mit den Mails passieren soll. Im Idealfall sollen diese natürlich abgelehnt werden.

[UPDATE]

Wir hatten geschrieben, dass der Mailserver den Empfang ablehnt, wenn der Name oder die IP-Adresse nicht in der Liste der zugelassenen Systeme zu finden ist.

Dies ist bei unseren Systemen und denen vieler anderer Provider durchaus der Fall. Dennoch gibt es technisch kein Muss für die Ablehnung. Die Spezifikation ermöglicht lediglich das Ablehnen. Die Formulierung in der Liste der Domains (ebay.de, ebay.com, dpd.de etc.) sollte daher anstelle «Ablehnung kein Muss» besser «Ablehnung sollte nicht vorgenommen werden» heißen. In der Konsequenz kommen so aber wie bereits geschildert gefälschte Mails einfacher beim Empfänger an.

[UPDATE 09/2023]

Der ursprüngliche Artikel aus Februar 2020 ist heute leider immer noch aktuell. Oder aktueller denn je. Diesen Monat waren es insbesondere Nachrichten von lexoffice.de, die die Benutzer der Online-Buchhaltungssoftware von Haufe Lexware mit gefälschten Rechnungen dazu brachten, Trojaner zu installieren oder die Lizenzgebühren auf Drittkonten zu überweisen. Haufe hat aber schnell reagiert, aktuell sind SPF und DMARC im Einsatz.

Im September 2023 sieht die Nutzung der beschriebenen Technologien wie folgt aus:

t-online.de | kein Postausgangsserver per SPF definiert
telekom.de | kein Postausgangsserver per SPF definiert
bundesregierung.de | SPF definiert, keine Überwachung per DMARC
niedersachsen.de | SPF definiert, keine Überwachung per DMARC
oldenburg.de | SPF definiert, keine Überwachung per DMARC
brake.de | SPF, DKIM und DMARC im Einsatz :-)
ebay.de/ebay.com | Ablehnung kein Muss, Einsatz von DKIM/DMARC und spf2.0
dpd.de/dpd.com | Ablehnung kein Muss, weiter keine Überwachung per DMARC
otto.de | SPF, DKIM und DMARC im Einsatz.
lufthansa.de | SPF, DKIM und DMARC im Einsatz, Ablehnung aber kein Muss
gruene.de | SPF definiert, Ablehnung kein Muss keine Überwachung per MRC
spd.de | Ablehnung kein Muss, keine Überwachung per DMARC
fdp.de | Ablehnung kein Muss, DMARC im Einsatz

DIe Liste entspricht den Texts aus Februar 2020. Einige Absender-Administratoren haben die notwendigen Maßnahmen umgesetzt, leider aber viele noch nicht.

Alle News anzeigen