Der (Un)Sinn von Greylisting

Mein letzter Post ist schon ein paar Wochen her. Seit dem habe ich mich viel mit dem Thema E-Mail beschäftigt. Man glaubt ja gar nicht, wie umfangreich das Thema ist. :-D

Heute möchte ich ein Stichwort heraus picken: Greylisting.

Was ist Greylisting?

Mit Greylisting soll Spam vermieden werden. Dabei geht man davon aus, das Spammer eine Mail nur einmal zuzustellen versuchen und nach einem fehlerhaften Versuch aufgeben. Des Weiteren geht man davon aus, dass vertrauenswürdige Absender aber sehrwohl mehrfache Zustellversuche unternehmen.

Wie funktioniert Greylisting?

Nehmen wir an Server A will eine Nachricht von abc@a.test an den Empfänger xyz@b.test senden und sendet die Mail deshalb an den MX-Server B. Nehmen wir außerdem an, dass auf dem Server B der MTA Postfix mit der Postgrey-Erweiterung läuft. In dem Fall bildet Postgrey das Triplett aus Client-IP, Sender und Empfänger und prüft, ob es in seiner Datenbank ein Match gibt, das älter als 5 Minuten ist. Falls ja, dann wird die Mail angenommen. Existiert das Triplett aber nicht oder wurde es erst in den letzten 5 Minuten hinzugefügt, dann wird die Mail mit einem REJECT temporär abgelehnt.

Der Mailserver des Absenders probiert im Normalfall später einen neuen Zustellversuch, der dann erfolgreich sein sollte. Spammer tun sich das lokale Queueing hingegen nicht an, verwerfen die Mail und man hat sich den Spam so erspart.

Was ist nun aber das Problem von Greylisting?

Das erste Problem ist, dass nicht alle Server einen neuen Zustellversuch unternehmen. Speziell wenn es es sich um eine automatisierte Mail handelt (etwa eine Registrierung auf einer Webseite), kann man nicht darauf vertrauen, dass der MTA des Webservers mehrere Zustellversuche unternimmt.

Das zweite Problem ist die Frequenz der Zustellversuche. Man weiß nie genau, wie oft der absendende Server versucht eine Mail zuzustellen. Probiert er es nach 1 Minute noch einmal, dann wird die Mail wieder abgelehnt, weil die 5 Minuten noch nicht vorbei sind. Probiert er es erst nach 5 Stunden, dann kommt die Mail einfach viel zu spät an. Ich hatte bei meinen Tests in den letzten Wochen selbst schon einige Fälle, bei denen Mails erst nach ein paar Stunden oder gar erst am nächsten Tag am Ziel ankamen.

Das dritte Problem ist die Bildung des Tripletts. Früher, als noch jede Mail von einem bestimmten Mailserver bearbeitet wurde, ließ sich so ein Triplett gut bilden. Der Empfängerserver B wusste somit immer, dass eine Mail vom Absender abc@a.test immer vom Absenderserver A kommt. Heutzutage, in Zeiten der Cloud, kann man dies nicht mehr sagen. Nutzt man einen Cloud-Service zum Senden der Mails (ich denke da etwa an Microsoft Exchange Online oder Google Apps), dann kann eine Mail von einen fast unendlichen Anzahl von Absenderservern zugestellt werden. Microsoft hat für Exchange Online etwa IP-Ranges mit gesamt 374.218 IP-Adressen (!) definiert. (Siehe TechNet) Selbst wenn also heute eine Mail zugestellt wurde (und das Triplett am Server B gespeichert ist), so heißt das noch lange nicht, dass eine Mail vom selben Absender an den selben Empfänger morgen auch direkt durch kommt. Möglicherweise verwendet der Absender ja Exchange Online und die Mail wird über eine der 374.217 anderen Adressen versendet…

Fazit

Aus meiner Sicht entspricht Greylisting nicht mehr dem Stand der Technik. Es mag zwar durchaus eine wirkungsvolle Methode zur Bekämpfung von Spam sein, aber die Nachteile die dieser Mechanismus mit sich bringt sind für meinen persönlichen Geschmack zu groß. Ich würde deshalb vorgeschaltete Filterdienste (aus der Cloud) bevorzugen. Statt prophylaktisch zuerst alles zu blocken, bis man dem Absenderserver nach dem zweiten Zustellversuch “vertraut”, können diese gezielte Backlists vom Spam-Servern verwalten und dies mit weiteren Mechanismen kombinieren. Das ist aber eine Sache die sich nur realisieren lässt, wenn man entsprechend viele Mails bearbeitet. Zusätzliche Features wie etwa Sandboxing und URL Protection gibt es bei den meisten Anbietern mittlerweile noch oben drauf.