Wider die E-Mail-Massen

Inhaltsverzeichnis

Es gehört schon eine Menge dazu, wenn „verfeindete“ Unternehmen wie Microsoft, AOL und Yahoo gemeinsame Sache machen. Die zunehmende Spam-Flut zwang die drei Unternehmen, die zu den größten E-Mail-Providern zählen, an einen Tisch. Gemeinsam wollen sie Standards entwickeln, um Spammern das Leben schwer zu machen.

Als „Anti Spam Technical Alliance“ (ASTA) hat der Zusammenschluss im Juni Empfehlungen für Internet- und Mail-Dienstleister herausgegeben [1|#literatur] . Er rät den Unternehmen, den Mail-Verkehr zu überwachen und Kunden-PCs sofort vom Netz zu trennen, wenn diese plötzlich große Mengen von E-Mails versenden. AOL macht nach eigenen Angaben in solchen Fällen den Zugang dicht.

Nach Erfahrung von Providern und Schätzung von Experten stammen 30 bis 40 Prozent der Spam-Mails von so genannten Zombie-PCs, die mit Würmern wie Sober.H oder Trojanern wie Randex infiziert sind und ohne Wissen ihrer Besitzer zum Versand des Werbe-Mülls missbraucht werden [2|#literatur] . Deshalb schlagen die ASTA-Mitglieder vor, dass Provider bei Privatkunden den Versand von Mails auf wenige Hundert pro Tag begrenzen.

Viele der ASTA-Vorschläge entsprechen längst in weiten Teilen des Netzes praktizierten Verfahren. So konnte ursprünglich Post an beliebige Benutzer an beliebigen Mailservern abgeliefert werden, die sich dann um die Weiterleitung an den Adressaten kümmerten.

Mittlerweile sind viele dieser „offenen Relays“ wie von der ASTA gefordert geschlossen worden. Noch vorhandene offene Relays (oder auch ihre Betreiber) werden in so genannten Realtime Blackhole List erfasst, auf die Mail-Provider zugreifen können. Spam-Filter sortieren E-Mails aus, die von dort verzeichneten Servern oder Domains stammen, was wiederum Druck auf die Betreiber ausübt, ihre offenen Server zu schließen.

Die Wurzel des Übels

Erfolgversprechender als Empfehlungen der ASTA an Internet-Provider sind Bestrebungen, die auf Änderungen des E-Mail-Transports generell abzielen. Heute nehmen Mailserver im Allgemeinen nur Mail von und für die Benutzer entgegen, für die sie zuständig sind, das aber von jedem Rechner des Netzes. Da es nur noch wenig offene Relays gibt, gehen die Spammer mehr und mehr dazu über, die Spam direkt beim Mailserver des Opfers abzukippen. Warum das derzeit klappt, veranschaulicht das Protokoll einer beispielhaften E-Mail-Übertragung.

Will ein Server eine E-Mail an einen Empfänger in einer anderen Domain schicken, so sucht er zunächst den zuständigen Mailserver mit einer DNS-Abfrage (Domain Name System). Für jede Domain, die Mails empfangen kann, steht dort der entsprechende Server im MX-Record. Ist der zuständige Server gefunden, verbindet sich der sendende mit dem empfangenden Server und setzt einige Kommandos ab (siehe Listing rechts).

Einträge im Domain Name System ermöglichen dem Empfänger bei RMX, CallerID, SPF und Co., Absender zu verifizieren.

Die Kommandos sind in RFC 2821 definiert (Simple Mail Transfer Protocol, SMTP), das Format der eigentlichen Nachricht (der Teil, der nach dem DATA kommt) in RFC 2822. Eines der wesentlichen Probleme ist, dass Absender (MAIL FROM) und Empfänger (RCPT TO) im Envelope nichts mit den Absender- und Empfängeradressen zu tun haben müssen, die in der eigentlichen Nachricht nach dem DATA Kommando stehen und die der Benutzer zu Gesicht bekommt. Das ist kein Bug von SMTP, sondern wurde von den Autoren des Protokolls explizit so vorgesehen.

Ein paar Worte zum Protokoll

Die BCC-Funktion (Blind Carbon Copy) wird beispielsweise durch mehrere RCPT-TO-Adressangaben für den Server realisiert. Auch bei Mailinglisten weichen die Envelope-Empfänger meist von den in der Nachricht angegebenen Empfängern ab; als Absender im „MAIL FROM“ wird häufig eine Adresse angegeben, hinter der ein Skript eventuelle Fehler interpretiert, denn dies ist die wichtigste Funktion des „MAIL FROM“: Es ist die Adresse, an die Benachrichtigungen über Fehler beim Zustellen gehen.

Spammer können durch die Trennung zwischen Envelope und Mail-Headern in den für den Benutzer sichtbaren Teil schreiben, was sie wollen - es hat keinen Einfluss auf die Zustellbarkeit der Mail. Schlimmer ist aber, dass von den Adressen, die im Envelope angegeben sind, nur die Empfängeradresse stimmen muss. Der Absender (und damit der Empfänger der Nachrichten über den Zustellstatus) wird gefälscht.

Mittlerweile achten die meisten Mailserver darauf, dass die Absenderdomain wenigstens existiert - schon über diese Abfrage lässt sich viel Spam blockieren. Nichtsdestotrotz wurden im Rahmen der Sober.H-Welle Unmengen fremdenfeindlicher E-Mails unter falschen Absenderadressen versendet. Eine riesige Flut von Benachrichtigungen über Zustellungsfehler und Beschwerden über vermeintliche Spam-Urheber war die Folge.

Kern aller Überlegungen, Spam beim empfangenden Mailserver zu bekämpfen, ist die Frage, wie man evaluiert, ob ein Server berechtigt ist, eine E-Mail mit einer bestimmten Absenderadresse anzuliefern. Eine Arbeitsgruppe (MTA Authorization Records in DNS, marid) der für Internet-Standards verantwortlichen Internet Engineering Task Force (IETF), an der auch die ASTA-Mitglieder mitwirken, sammelt Vorschläge hierfür, die in einen neuen RFC einfließen sollen [3|#literatur] .

Die Idee, DNS nicht nur zum Finden der Mailserver, sondern auch zum Definieren der legitimen Mailserver zu benutzen, ist dabei mehrfach aufgetaucht. Der erste Internet-Draft zu diesem Thema war RMX von Hadmut Danisch. Dieses Konzept wurde nie sehr populär, seine Grundidee aber in verschieden anderen Vorschläge übernommen, zum Beispiel in den von AOL präferierten Sender Permitted From (SPF) und in CallerID von Microsoft.

SPF und CallerID sehen im DNS gespeicherte Regeln vor, die beschreiben, welche Server E-Mails mit einer bestimmten Absenderdomain verschicken dürfen. Im SPF-Record

v=spf1 +mx -all  

zum Beispiel bedeutet +mx, dass die betreffenden Mailserver Mails senden dürfen, also diejenigen Server, die bereits mit einem MX-Record für die Entgegennahme von E-Mails legitimiert sind. -all schließt alle anderen Rechner vom Mail-Versand aus. Diese Regeln können relativ detailliert sein.

SPF und Co. würden hervorragend funktionieren, gäbe es nicht das Forwarding. Es erlaubt beliebigen Servern - völlig legitim - E-Mails mit der Absenderadresse einer anderen Domain weiterzuleiten. Dabei ändert der weiterleitende Server nur das RCPT TO und schickt die Nachricht an einen anderen Host weiter.

MAIL FROM: test@domain1.example  

RCPT TO: mfvm@domain2.example DATA From: test@domain1.example To: test@domain2.example

wird zu

MAIL FROM: test@domain1.example  

RCPT TO: mfvm@domain3.example DATA From: test@domain1.example To: test@domain2.example

Der Mailserver von domain3.example versendet also eine Mail mit der Absenderadresse aus der Domain domain1.example. Beim weiterleitenden Server würde also eine SPF-Anfrage ergeben, dass der Mailserver von domain3.example diese E-Mail nicht versenden darf, und die Benutzer des empfangenden Servers würden die E-Mail nicht erhalten. Die marid-Arbeitsgruppe diskutiert derzeit mehrere Vorschläge, wie das Forwarding-Problem gelöst werden könnte.

Alle RMX-ähnliche Vorschläge können nur funktionieren, wenn sich alle E-Mail-Provider daran beteiligen. Einstweilen kommen SPF, CallerID und Co. daher nur in Spam-Filtern wie SpamAssassin zum Einsatz. Das Vorhandensein eines gültigen SPF-Eintrags im DNS-Record der Absenderdomain wird dort als Hinweis, aber nicht als endgültiger Beleg gewertet, dass es sich bei einer E-Mail nicht um Spam handelt.

Allen Vorschlägen ist gemein, dass sie nur ein Mittel bereitstellen, die Frage nach der Legitimität zu beantworten. Welche Konsequenzen daraus für die Behandlung der E-Mail auf dem jeweiligen Server zu ziehen sind, können RFCs selbstverständlich nicht beantworten.

Vorschläge im Einzelnen

Im Unterschied zu den Vorschlägen, die komplexe Regeln im DNS vorsehen, soll bei MTAMARK im DNS nur festgehalten werden, ob ein Rechner Mailserver ist oder nicht: Ist er einer, darf er senden, ist er keiner, darf er nicht. Der Vorteil dieses Schemas ist, dass es keine Probleme mit dem Weiterleiten gibt. Da viel Spam-Mails und viele Würmer über direkt einliefernde Home-PCs kommen, könnte dieser Vorschlag nichtsdestotrotz viele Spam-E-Mails verhindern helfen. Auch könnte der Mailserver die Entscheidung „Mailserver oder nicht?“ schon in der Envelope-Phase treffen, also bevor viele Daten über die Leitung gegangen sind. Der Nachteil ist aber, dass ein Rechner, der als Server markiert ist, wirklich alles darf.

Yahoos Vorschlag namens DomainKeys läuft darauf hinaus, die komplette E-Mail mittels Public-Key-Technik mit einer Signatur zu versehen. Den zum Testen der Signatur nötigen öffentlichen Schlüssel legen die Betreiber der Domain im DNS ab, die Signatur wird zusammen mit einigen Zusatzinformationen in den Header geschrieben.

Dieser Vorschlag funktioniert nur nach der Übertragung der kompletten Mail-Daten. Ein Vorteil ist, dass im Idealfall eine erfolgreiche Prüfung der Mail nicht nur beweist, dass die Mail vom entsprechenden Server verschickt werden darf, sondern auch die Unversehrtheit der Mail belegt. Das wiederum ist auch schon der große Nachteil: Viele der heute benutzten Mailserver ändern Header oder ergänzen welche, was die Prüfung der Mail deutlich erschweren dürfte. Insgesamt ist das ein interessanter Vorschlag, aber die Umsetzung dürfte große Schwierigkeiten aufwerfen.

Ausblick

Microsoft, AOL und Yahoo haben ursprünglich unterschiedliche Verfahren bei der IETF eingereicht. Nun wollen zumindest Microsoft sein CallerID und Meng Weng Wong sein von AOL unterstütztes Sender Policy Framework (SPF) zu einem Verfahren kombinieren (Sender ID). Yahoo will dagegen an seiner Idee der Domain Keys festhalten. Die zwei Lager sind darin übereingekommen, beide Authentifizierungstechniken zu testen. Die SPF-Homepage listet bereits mehr als 20 000 Domains, die SPF-Records angelegt haben [4|#literatur] . Jeder Administrator, der Zugang zu seinem DNS-Record hat, kann heute schon SPF-Records hinzufügen. Ein Wizard auf der SPF-Homepage hilft beim Verfassen der Records.

Bis sich eine der Techniken als Standard herauskristallisiert, dürfte aber noch einige Zeit vergehen. Um in der Zwischenzeit nicht im Spam-Aufkommen zu ersticken, wie im Mai der Mailserver der Bundesregierung, muss sich der Administrator mit anderen Mitteln behelfen, zum Beispiel mit einem Server-seitigen Filter wie Spam Assassin oder dem NiX Spam unserer Schwesterzeitschrift iX [5, 6|#literatur] .

Spezielle Filter auf dem Posteingangs-Server können zusätzlich helfen, möglichst viele E-Mails in einem frühen Stadium der Übertragung abzufangen und somit die Systemlast insgesamt gering zu halten. So weist der Server des Heise-Verlags pro Tag zu Spitzenzeiten mehr als 40 000 E-Mails wegen eines ungültigen Empfängers ab, mehr als 15 000 wegen einer ungültigen Absenderadresse. Über 6000 entsorgt er aufgrund eines gefälschten HELO, etwa wenn der einliefernde Server die IP-Adresse des Heise-Relays als seine eigene angibt.

Mehr als 4000 Nachrichten fallen einer lokalen Blacklist zum Opfer; in mehr als 3500 Fällen wird die Verbindung abgebrochen, weil innerhalb der Verbindung zu viele falsche Adressaten angegeben werden (passiert häufig bei Würmern). Insgesamt eliminiert der Heise-Server an manchem Tag rund 80 000 E-Mails schon während der Übertragung.

Auch für den Benutzer bedeutet das Fehlen eines globalen Sicherungsmechanismus gegen Spam, dass er seine E-Mail filtern muss, zum Beispiel mit einem der Desktop-Programme, die der Artikel ab Seite 146 vorstellt. Aber auch das Aufkommen erwünschter E-Mails wächst und wächst. Der Beitrag ab Seite 154 erläutert, wie man mit den Mitteln der E-Mail-Clients und mit pfiffigen Tools den Überblick behält. Mitunter kann es sinnvoll sein, das E-Mail-Programm oder den Provider zu wechseln. Der Artikel ab Seite 158 veranschaulicht, wie man vorhandene E-Mail-Bestände bei einem Umzug mitnimmt. (jo)

Literatur

[1] Empfehlungen der ASTA

[2] Ferngesteuerte Spam-Armeen, Nachgewiesen: Virenschreiber lieferten Spam-Infrastruktur, c't 5/04, S. 18

[3] IETF-Arbeitsgruppe „MTA Authorization Records in DNS“

[4] SPF-Homepage

[5] Spam Assassin - mächtiger E-Mail-Filter, vornehmlich für den Server

[6] NiX Spam, E-Mail-Filter auf Procmail-Basis

"Schluß mit dem Mail-Chaos"
Weitere Artikel zum Thema Spamschutz finden Sie in der c't 15/2004:
Netzweite Anti-Spam-Techniken	S. 142
Lokale Spam-Filter	S. 146
E-Mail-Organisation	S. 154
Mail-Archiv umziehen	S. 158

(jo)