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

DNS Blacklists

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

127.0.0.5 

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);



Greylisting / Graylisting

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.


Sender Policy Framework (SPF)

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

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.


Domain Keys (DKIM)

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





FRESHMAIL 2009-2018