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 |
 Gering |
Gering |
Gering |
| Kompatibilität |
 Empfangender
Mailserver muss SPF unterstützenKeine Änderung am Sender |
Empfangender
Mailserver muss DKIM unterstützen Sender muss Hash errechnen und voranstellen |
Mailserver
muss TLS unterstützen und prüfen. |
| CPU-Last |
Gering |
Mittel
(Hashwert generieren) (Hashwert prüfen) |
Mittel 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 |
Mittel. Auch Spammer können SPF-Records pflegen. Effektiver in Verbindung mit Domain-Sperr/Allow Listen |
Mittel. Auch Spammer können selbst signieren. Effektiver in Verbindung mit Domain-Sperr/Allow Listen |
Mittel
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 |
 Nein |
Nein |
JA,
SSL |
| Frühester Abwehrzeitpunkt | CONNECT beim Verbindungsaufbau vor dem HELO/EHLO |
QUIT Signatur erst nach dem kompletten Empfang möglich. |
HANDSHAKE Nach dem Aushandeln der TLS-Daten vor der Mailübertragung |
| Routing über Relay |
Mittel Relay muss auch im SPF-Record auftauchen |
Problemlos Die Mail selbst ist signiert. Weitere Headerzeilen stören nicht, solange diese voran gestellt werden |
Knifflig SSL-Zwang kann nicht auf dem gesamten Weg erzwungen werden. Besser ist immer direkte Zustellung. |
| Listserver |
Rewriting
erforderlich |
Unverändert
kopierte Mail geht weiter durch. Nur wen Absender, Empfänger im Body
verändert werden, muss neu signiert werden. |
Rewriting
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 Smarthosts 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).
