Im Folgenden eine Auflistung möglicher Techniken und Wege, den Empfang
von Spam E-Mail zu unterbinden oder zumindest vermindern.
DNS Blacklists
Greylisting
Sender Policy Framework (SPF)
Sender ID
Domain Keys (DKIM)
Konformitätstests
Textanalysen
Bei dieser Technik wird die IP Adresse des Mail Einlieferers benutzt, um damit
eine Anfrage bei einer oder mehreren DNS Blacklists zu starten.
Eine bestimmte Antwort bedeutet, die angefragte IP ist sehr wahrscheinlich
die IP eines Computers, der Spam verschickt (oder verschickt hat).
Funktionsweise
Für den Aufbau einer DNSBL (DNS Blackhole List) verwendet man einen
normalen DNS Server. Die Einträge in einer solchen Blacklist sind IPs
von Maschinen, die als Spam versendende Hosts aufgefallen sind. Die IPs
sind üblicherweise als normale Zonen auf dem DNS Server eingetragen.
Die IP Adressen werden als Subdomains eingetragen:
Aus der IP Adresse
wird die Subdomain
5.0.0.127.dnsbl.example.com
|
Der Inhalt einer Zonendatei für diese IP/Subdomain könnte so aussehen:
5.0.0.127.dnsbl.example.com IN A 127.0.0.3
5.0.0.127.dnsbl.example.com IN TXT "Go away, Spammer!"
|
Die IP Adresse 127.0.0.2 wird üblicherweise als Testadresse genutzt.
Die Antwort ist positiv in dem Sinne "Die IP gehört einem Spammer", wenn
die Antwort 127.0.0.* (* > 1 bzw. 2) ist.
Ist die IP nicht gelistet, erhält man gar keine Antwort.
Sie können eine Blacklist mit einem simplen nslookup testen:
# nslookup 2.0.0.127.zen.spamhaus.org
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: 2.0.0.127.zen.spamhaus.org
Address: 127.0.0.2
Name: 2.0.0.127.zen.spamhaus.org
Address: 127.0.0.4
Name: 2.0.0.127.zen.spamhaus.org
Address: 127.0.0.10
|
Nochmal das Gleiche, aber wir wollen auch den TXT Record:
# nslookup -type=TXT 2.0.0.127.zen.spamhaus.org
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
2.0.0.127.zen.spamhaus.org text = "http://www.spamhaus.org/SBL/sbl.lasso?query=SBL233"
2.0.0.127.zen.spamhaus.org text = "http://www.spamhaus.org/query/bl?ip=127.0.0.2"
Authoritative answers can be found from:
zen.spamhaus.org nameserver = 3.ns.spamhaus.org.
zen.spamhaus.org nameserver = 5.ns.spamhaus.org.
(...)
|
Wenn man den Links folgt, findet man eine kurze Erklärung und den Hinweis,
das die IP als die eines Spammers gelistet ist.
Das folgende Perl-Skript macht das Gleiche, jedoch gibt es die
Informationen via Dumper aus.
#!/usr/bin/perl
use Data::Dumper;
## create a new resolver object
use Net::DNS::Resolver;
my $res = new Net::DNS::Resolver;
## not more than 10 seconds
$res->tcp_timeout(10);
$res->udp_timeout(10);
## put the good ones in this file
$packet = $res->query("2.0.0.127.spamsources.fabel.dk", "TXT");
print Dumper($packet);
|
Bei dieser Technik geht es im Prinzip darum, Mails von Unbekannten zunächst
erstmal abzulehnen - mit irgendeiner Begründung eines temporären Fehlers.
Ein korrekt arbeitender Mailserver, der eine Mail loswerden will, wird es zu
einem späteren Zeitpunkt nochmal probieren. Der empfangende Mailserver "merkt"
sich die Versuche des sendenen Mailservers und nimmt nach konfigurierbaren Zeiten
des Ablehnens die Mail letztendlich an. Der Grundgedanke dahinter ist die Erfahrung, dass
Spammer lediglich einmal probieren eine E-Mail auszuliefern. Scheitert der Versuch,
so wird die nächste Zieladresse probiert. Greylisting gilt als eines der
zuverlässigsten Verfahren und wird von einem breiten Angebot an Software
unterstützt.
Funktionsweise
Es gibt bei den verschiedenen Implementierungen leichte Unterschiede und/oder
Möglichkeiten einzelne Parameter zu konfigurieren. Hier geht es aber erst einmal
um die eigentliche Funktionsweise.
Wenn ein Mailserver eine Mail erhält, bekommt er zunächst den
Envelope.
Darin enthalten sind:
- E-Mail Adresse des Senders
- E-Mail Adresse des Empfängers
Dazu kennt der empfangene Mailserver noch die IP Adresse des Senders. Die
Greylisting Software prüft nun, ob schonmal eine E-Mail in einer identischen
Kombination empfangen worden ist. Also:
- Gleicher Sender
- Gleicher Empfänger
- Gleiche IP Adresse (anzunehmen, gleicher Mailserver)
Ist diese Kombination neu, wird eine Meldung zu einem temporären Fehler
ausgegeben (Fehler mit 4** Code) und somit erst einmal abgelehnt. Die meisten Implementierungen
sind konfigurierbar im Hinblick auf die Dauer des Ablehnens einer neuen
Kombination.
Ist die Kombination bekannt, wird die E-Mail sofort angenommen.
Üblicherweise werden Informationen darüber, welche Kombinationen bekannt
sind, in internen Whitelists geführt.
Diese Technik setzt voraus, dass alle teilnehmenden Mailserver sich
entsprechend den Vereinbarungen
(
RFCs) verhalten.
SPF wurde zu dem Zweck erdacht, das Fälschen von Absenderadressen
zu erschweren. Der angenehme Nebeneffekt ist, dass dadurch auch weniger
Spam eingeliefert wird. Tatsächlich funktioniert die Technik, sofern
man den Schutz etwas auflockert und als "Schutz vor dem Fälschen eines
Mail Relays" betrachtet.
Funktionsweise
Der DNS Zone einer Domain wird ein zusätzlicher Eintrag hinzugefügt. Dieser
sog. Resource Record ist vom Typ SPF oder TXT. Der Eintrag enthält
Informationen darüber, von welchen IP Adressen E-Mails einer bestimmten
Domain gesendet werden dürfen.
Sehen wir uns als Beispiel gmx.de an:
$ nslookup -type=TXT gmx.de
Server: 192.168.100.1
Address: 192.168.100.1#53
Non-authoritative answer:
gmx.de text = "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 -all"
|
Sehen wir uns folgendes Szenario an: Ein GMX Kunde sendet eine E-Mail
an einen Bekannten, der seine E-Mail Adresse bei Hotmail hat.
Der GMX Server verbindet sich zu einem Hotmail Mailserver. Der
Hotmailserver nimmt den Envelope des GMX Servers an und überprüft
die Angaben. Dazu schaut er in den TXT Record von gmx.de.
Dort findet er die Angabe:
v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 -all
|
Er wird kontrollieren ob die IP des vermeintlichen GMX Mailservers
tatsächlich in den IP Bereich fällt, der im TXT Record zu gmx.de
angegeben ist. Ist das nicht der Fall, wird die E-Mail abgelehnt.
Ansonsten wird die E-Mail angenommen und zugestellt.
In
RFC 4408 wurde spezifiziert,
dass das MAIL FROM, sowie die HELO Angaben geprüft werden sollen.
Die E-Mail Header werden nicht untersucht.
Die dunkle Seite von SPF
SPF erzeugt bei allem Respekt für die eigentliche Idee eine ganze Reihe
von Problemen.
Weiterleitungen
Wird eine E-Mail von einer Domain mit einem SPF Record weitergeleitet und
nutzt das letztendliche Zielsystem ebenfalls SPF Records, um die
Authentizität einer E-Mail Adresse zu prüfen, so würde eine solche
weitergeleitete E-Mail abgelehnt. Das weiterleitende System wäre nicht im
SPC Record der Absenderdomain aufgeführt.
Um das Problem zu lösen gibt es drei Lösungsansätze:
Die radikalste Lösung wäre, SPF Prüfungen zu deaktivieren.
Eine andere Möglichkeit ist es, eine Whitelist zu verwenden. Allerdings
muss man dabei im Vorfeld wissen, welche Absenderadressen ins System kommen
könnten.
Eine dritte Möglichkeit ist, auf dem weiterleitenden System ein
Überschreiben des Envelopes durchzuführen (SRS, Sender Rewriting Scheme).
Hier muss jedoch beachtet werden, dass das weiterleitende System auch Bounces
an diese E-Mail Adresse managen müsste. In der Praxis ist eine sorgfältige
Implementierung jedoch nicht die Regel.
Für Webentwickler kann es u.U. zu einem Ärgernis werden, wenn sie
Software entwickeln, die Nutzereingaben als Absenderadressen verwenden.
ZB. in Webformularen, wo ein Nutzer eine Empfehlung für ein Produkt
in seinem Namen (und seiner E-Mail Adresse) versenden kann. In diesem Fall
wird der Entwickler das Problem möglicherweise erst spät oder sogar gar
nicht bemerken.
SPF ist von einigen Stellen auch wegen der Möglichkeit Spam zu filtern
gelobt worden. Mittlerweile sind jedoch auch Spammer dazu übergegangen,
SPF Einträge in ihre eigene Domainverwaltung zu integrieren.
Sender ID war seinerzeit ein Vorschlag einer IETF Arbeitsgruppe.
Die Technik stützt sich auf SPF und eine von Microsoft entwickelte
Technik "Caller ID".
Aufgrund von Differenzen in Lizenzfragen hat die Arbeitsgruppe die
Entwicklung mittlerweile eingestellt.
Prinzipiell soll Sender ID das Fälschen von Absender und Domainspoofing
verhindern. Wenn man die Informationen von
Microsoft dazu liest, wird man schnell feststellen, dass es sich im Grunde
lediglich um die Nutzung von SPF handelt. Das Sender ID Framework übernimmt
die Aufgabe, die Mailabsender gegen SPF Records zu testen.
DomainKeys ist ein von Yahoo entwickeltes Identifikationsprotokoll. Auch
DomainKeys ist entstanden um Spamempfang einzudämmen und Authentizität von
E-Mails zu gewährleisten. Als erstes wurde es unter
RFC 4870 spezifiziert,
welches dann von
RFC 4871
abgelöst wurde.
DKIM dient, wie auch SPF, primär dazu, das Verschleiern von Absenderadressen
zu erschweren. DKIM dient nicht dazu, Spam zu unterbinden, auch wenn es
ein angenehmer Nebeneffekt sein kann.
Funktionsweise
Jeder Mail wird eine digitale Signatur hinzugefügt. Die Signatur basiert auf
einer asymetrischen Verschlüsselung. In einem DNS Record der Senderdomain
wird der öffentliche Schlüssel hinterlegt. Mit dessen Hilfe, kann ein
empfangendes System die Gültigeit der Signatur prüfen. Die Signatur soll
von dem sendenen System, dem
E-Mail Header
hinzugefügt werden. Die Signatur wird Base64 kodiert.
Für die Erstellung der Hashwerte unterstützt DKIM SHA-1 und SHA-256.
Die Verschlüsselung des Hashes wird mit RSA durchgeführt.
Das empfangende System dekodiert zunächst die Base64 kodierte Signatur.
Danach wird mithilfe des öffentlichen Schlüssels der Hashwert der E-Mail
neu berechnet und mit der zuvor dekodierten Signatur verglichen.
Stimmen die Signaturen überein, kann man von einer authentischen E-Mail
ausgehen. Gibt es keine Übereinstimmung, kann Manipulation im Spiel sein.
Links