Spam und UCE - Ratingmechanismen

Diese Seite ist ein Entwurf und wird sicher noch häufiger verändert und angepasst.

Alle drei Verfahren versuchen das Thema Spam aber viel mehr auch das Phishing zu reduzieren, indem der Absender mithilft seine Identität oder die Gültigkeit der Mail zu bestätigen.

Das Problem

Die Bekämpfung von Spam und Viren ist bei den meisten Programmen ein Prozess, der erst nach dem Empfang der Mail in Aktion treten kann. Erst dann ist der Inhalt vorhanden und kann durch verschiedene Filter verarbeitet und bewertet werden. Nur wenige Filter, wie z.B. RBL arbeiten auf einem sehr frühen Level und lehnen Verbindungen von Systemen ab, die laut der Liste ein offenes Relay sind. Damit ist RBL schon eine erste Form eines" Ratings" einer IP-Adresse. Ein weiteres Beispiel sind z.B. Listen mit Wählverbindungen zum Internet (DUL). Diese vergleichsweise einfachen Listen funktionieren aber nur zu einem gewissen Grade und blockieren teilweise auch irrtümlich Mailversender, während Sie auf der anderen Seite durch professionelle Spammer einfach umgangen werden können.

Die beschriebenen Verfahren

Durch den Verzicht auf die Anonymität und die Preisgabe einiger Informationen können "gute" Sender und Empfänger aber Wege entwickeln, die eine unterscheidung von unerwünschten Nachrichten einfacher zulassen. Folgende drei Verfahren werden in einem kurzen Vergleich gegenüber gestellt.

  • SPF/CallerID
    Der Absender veröffentlicht im Internet die IP-Adresse seiner "ausgehenden Mailserver"
  • DKIM/Domainkey
    Der Absenderserver signiert die Mails digital und stellt den Public Key zur Prüfung per DNS bereit.
  • TLS SSL mit Zertifikaten
    Über den SMTP-Standard "TLS" werden Mails verschlüsselt und signiert. Der Empfänger kann den Absenderserver identifizieren. öffentliche Zertifikate sind ratsam. Private Zertifikate möglich zur Verschlüsselung aber als Schutz sind auch hier noch Verfahren zur Veröffentlichung des eigenen Public Keys (DNS o.ä.) zu entwickeln.

Verschiedene Reputationsdatenbanken kommerzieller Anbieter sind nicht Bestandteil des Vergleichs. (Siehe auch Reputation). Der Ansatz "TLS SSL mit Zertifikaten" steckt noch in den Kinderschuhen aber wurde von mir aufgrund des Potentials hier mit in die Bewertung einbezogen.

Alle Verfahren sind natürlich zuerst einmal "Positiv"-Verfahren, mit dem sich gute Absender auszeichnen können und damit die Arbeit den Spamfiltern erleichtern. Wirklich wirksam sind die Mechanismen eher gegen Phishing, d.h. dass ein Absender sich als jemand anderes ausgibt. Eine Spamabwehr wird es erst dann, wenn die gewonnenen Informationen über den Absender mit einer "Ratingdatenbank" verknüpft werden.

Rating im Vergleich

Eine tabellarische Übersicht einiger Funktionen macht den Vergleich einfacher.

Kriterium SPF DKIM TLS

Prüfkriterium

IP-Adresse des einliefernden Servers gegen im DNS hinterlegte Daten

Digitale Signatur jeder Mail gegen einen im DNS hinterlegten Public Key

SSL-Zertifikat über den Namen oder Datenbank

Sicherung des

Host
IP-Adresse ist zugelassen

Mail
Mail wurde von der Domain ursprünglich erstellt.

Host/Mail
Mail kommt von Host mit Domainzertifikat

Kosten

JaGering

JaGering

JaGering

Kompatibilität

MittelEmpfangender Mailserver muss SPF unterstützen
Keine Änderung am Sender

MittelEmpfangender Mailserver muss DKIM unterstützen
Sender muss Hash errechnen und voranstellen

MittelMailserver muss TLS unterstützen und prüfen.

CPU-Last

JaGering

MittelMittel
(Hashwert generieren)
(Hashwert prüfen)

MittelMittel
SSL-verschlüsselung

Sicherheit gegen Fälschung

Hoch, IP kann eigentlich nicht gefälscht werden.

Hoch, Domainkey kann eigentlich nicht gefälscht werden.

niedrig bis Hoch
Abhängig vom Zertifikat.

Spamschutz

MittelMittel.
Auch Spammer können SPF-Records pflegen. Effektiver in Verbindung mit Domain-Sperr/Allow Listen

MittelMittel.
Auch Spammer können selbst signieren. Effektiver in Verbindung mit Domain-Sperr/Allow Listen

MittelMittel bis Hoch
je nach Einbeziehung der Daten im Zertifikat

Phishingschutz

Hoch
Wenn die potentiellen Phisingdomains alle SPF Einträge haben. (leider nicht der Fall)

Hoch
Wenn die potentiellen Phisingdomains alle DKIM nutzen. (leider nicht der Fall)
Störpotential durch Resend

Mittel bis Hoch
je nach Einbeziehung der Daten im Zertifikat

Verschlüsselung

NeinNein

NeinNein

JaJA,  SSL

Frühester Abwehrzeitpunkt

CONNECT
beim Verbindungsaufbau vor dem HELO/EHLO

NeinQUIT
Signatur erst nach dem kompletten Empfang möglich.

HANDSHAKE
Nach dem Aushandeln der TLS-Daten vor der Mailübertragung

Routing über Relay

MittelMittel
Relay muss auch im SPF-Record auftauchen

JaProblemlos
Die Mail selbst ist signiert. Weitere Headerzeilen stören nicht, solange diese voran gestellt werden

MittelKnifflig
SSL-Zwang kann nicht auf dem gesamten Weg erzwungen werden. Besser ist immer direkte Zustellung.

Listserver

MittelRewriting erforderlich

JaUnverändert kopierte Mail geht weiter durch. Nur wen Absender, Empfänger im Body verändert werden, muss neu signiert werden.

MittelRewriting erforderlich, wenn das Zielsystem den Absender mit dem Zertifikat prüft.

Bewertung

Alle drei "Lösungen" kranken daran, dass Sie erst dann ihre Stärke ausspielen können, wenn viele Versender mit machen. Das ist leider nicht der Fall und bei SPF und DKIM ist die Einführung erst einmal mit Arbeit verbunden, ohne dass ein direkter spürbarer Nutzen damit verbunden wäre. Einzig die TLS-Variante hat den Vorteil, dass allein durch ein privates Zertifikat beim Empfänger schon eine Verschlüsselung möglich wäre. Dies könnte der Schlüssel dazu sein, dass Firmen damit anfangen, eigene oder öffentliche Zertifikate installieren und mit Partnern TLS erzwingen. Sollte es einmal einen Standard geben, könnten auch private Zertifikate natürlich über DNS (analog zu SPF/DKIM) als vertrauenswürdig publiziert werden, um die Kosten kommerzieller PKIs zu umgehen.

Erklärung zu den Kriterien

  • Prüfkriterium
    Kurze Erklärung, wie das Verfahren arbeitet
  • Sicherung des
    Beschreibung, was diese Prüfung gewährleistet. Bei SPF wird geprüft, dass der Host legitimiert ist, DKIM verspricht, dass die Absenderdomain korrekt ist.
  • Kosten
    Die Kosten zur Implementierung sind durchweg gering, wenn der Mailserver die Funktion bereits unterstützt. Bei TLS können zwar die Kosten für ein öffentliches Zertifikat hinzu kommen, aber dies ist nicht pflicht.
  • Kompatibilität
  • CPU-Last
    SPF braucht kaum CPU-Zyklen, während bei DKIM schon mehr zu errechnen ist. Auch TLS benötigt mehr CPU-Ressourcen für die SSL Verschlüsselung.
  • Sicherheit gegen Fälschung
    SPF und DKIM sind kaum zu fälschen während die Qualität von Zertifikaten natürlich von der ausstellenden CA bzw. der sicheren Verfügbarkeit des dazugehörigen Fingerprints bzw. RootCA abhängt.
  • Spamschutz
    Alle Varianten sind eigentlich "Positiv"-Lösungen, die eine Mail als vertrauenswürdig klassifizieren können. Daher eigenen Sie sich für sich alleine weniger als Spamschutz. Wenn irgendwann wirklich jeder "gute" Sender nicht mehr anonym bleiben will, dann kann hieraus jedoch ein effektiver Schutz entstehen.
  • Phishingschutz
    DKIM und SPF schützen gegen Phishing Mails. Allerdings muss dazu die entsprechende Domain mit einem entsprechenden Eintrag im DNS unterstützen, was leider noch lange nicht der Fall ist. TLS hingegen würde erst dann schützen, wenn anhand des Zertifikats der Gegenstelle eine Mail abgelehnt werden würde.
  • Verschlüsselung
    Nur TLS erlaubt eine Verschlüsselung der Nachrichten. SPF oder DKIM schützen nicht die Nachricht gegen "Abhören" auf dem Kabel. Allerdings schützt TLS auch nicht gegen die ungesicherte Zwischenspeicherung auf einem Relay oder Backup-MX.
  • Frühester Abwehrzeitpunkt
    Spam verursacht Kosten. Daher ist es wichtig, eine nicht erwünschte Mail möglichst früh abzulehnen. Dies schaffen SPF und TLS problemlos. DKIM hingegen muss erst die komplette Mail empfangen, ehe diese als ungültig erkannt werden kann.
  • Routing über Relay
    Früher wurden Mails sehr oft über Smarthost versendet und über Backup-MX-Server empfangen. Heute ist es fast normal, dass jede Firma direkt eine Verbindung zum Mailserver des Empfängers aufbauen. Sollte ein Relay erforderlich sein, dann ist bei DKIM fast nichts zu beachten. Bei SPF muss ein ausgehendes Relay mit in die Liste der autorisierten Versendet aufgenommen werden.
  • Listserver
    Listserver verteilen eine Mail an die eingeschriebenen Teilnehmer. Wird dabei der Absender nicht verändert, dann würde SPF natürlich diese Mails ablehnen.  Bei DKIM müsste die Mail neu signiert werden, wenn der Absender sich ändert (z.B. auf die Listserveradresse).

Weitere Links