Greylisting beruht auf der Annahme, dass legitime Mail-Server nach einem temporären Fehler die Mail queuen und in regelmäßigen Abständen versuchen, die Mail erneut zuzustellen, und dass Spamware und Würmer das aber nicht machen. Wenn man also Mails mit unbekannter Kombination (Relay, From, To) zunächst ablehnt, und nur innerhalb eines bestimmten Zeit-Fensters nach dem ersten Zustellungsversuch annimmt, kommen Mails von Mailservern durch, solche von Spamware und Würmern aber nicht.
Wir verwenden die Implementation von Gavin Carr für qpsmtpd.
Ein Beispiel
Ian hat mir einige Logeinträge zugeschickt, an denen man schön den Effekt des Greylistings sieht. Das folgende ist im Wesentlichen meine Antwort an ihn. Seine Logfileeinträge zitiere ich mit grauem Hintergrund, die dazupassenden des Servers mit gelbem Hintergrund darunter (die Zeitstempel passen nicht ganz zusammen. Midoris Uhr ging offenbar ca. 17 Sekunden vor. Außerdem habe ich die Domainnamen und IP-Adressen verfälscht.).
| Aug 28 00:35:16 | midori sendmail[26322]: | h7RMZD426320: to=luga@luga.at, ctladdr=ian (500/100), delay=00:00:03, xdelay=00:00:03, mailer=esmtp, pri=120871, relay=arachne.luga.at. [143.130.20.2], dsn=4.2.0, stat=Deferred: 450 This mail is temporarily denied |
| 2003-08-28T00:34:59 | 20164 | denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at initial DENYSOFT, unknown |
| 2003-08-28T00:34:59 | 20164 | 450 This mail is temporarily denied |
Das ist die erste Mail, die von 1.2.178.70 mit Absender ian@midori.beispiel.at an Empfänger luga@luga.at geschickt wurde. Also wird sie erstmal abgelehnt und diese Kombination IP:FROM:RCPT in die Blacklist eingetragen.
| Aug 28 00:47:31 | midori sendmail[26402]: | h7RMZD426320: to=luga@luga.at, ctladdr=ian (500/100), delay=00:12:18, xdelay=00:00:03, mailer=esmtp, pri=210871, relay=arachne.luga.at. [143.130.20.2], dsn=4.2.0, stat=Deferred: 450 This mail is temporarily denied |
| 2003-08-28T00:47:14 | 20214 | denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at black DENYSOFT - 1 failed connections |
| 2003-08-28T00:47:14 | 20214 | 450 This mail is temporarily denied |
Die Kombination ist jetzt bekannt, aber in der Blacklist. Noch ein Deny.
| Aug 28 01:17:31 | midori sendmail[26580]: | h7RMZD426320: to=luga@luga.at, ctladdr=ian (500/100), delay=00:42:18, xdelay=00:00:03, mailer=esmtp, pri=300871, relay=arachne.luga.at. [143.130.20.2], dsn=4.2.0, stat=Deferred: 450 This mail is temporarily denied |
| 2003-08-28T01:17:15 | 20446 | denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at black DENYSOFT - 2 failed connections |
| 2003-08-28T01:17:15 | 20446 | 450 This mail is temporarily denied |
| Aug 28 01:47:32 | midori sendmail[26785]: | h7RMZD426320: to=luga@luga.at, ctladdr=ian (500/100), delay=01:12:19, xdelay=00:00:04, mailer=esmtp, pri=390871, relay=arachne.luga.at. [143.130.20.2], dsn=2.0.0, stat=Sent (Queued!) |
| 2003-08-28T01:47:15 | 20620 | denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at updated grey->white |
| 2003-08-28T01:47:15 | 20620 | running plugin check_relay |
Seit dem ersten Zustellversuch sind zwischen 1 und 3 Stunden vergangen. Die Kombination ist daher inzwischen in der Greylist. Die Mail wird daher angenommen und die Adresse in die Whitelist eingetragen.
| Aug 28 12:59:15 | midori sendmail[30740]: | h7SAxAb30738: to=luga@luga.at, ctladdr=ian (500/100), delay=00:00:05, xdelay=00:00:04, mailer=esmtp, pri=122516, relay=arachne.luga.at. [143.130.20.2], dsn=2.0.0, stat=Sent (Queued!) |
| 2003-08-28T12:59:01 | 26859 | denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at is white, 2 deliveries |
| 2003-08-28T12:59:01 | 26859 | 250 luga@luga.at, recipient ok |
Die Kombination ist bekannt, daher wird die Mail sofort angenommen.
| Aug 28 18:05:05 | midori sendmail[32332]: | h7SG51g32330: to=luga@luga.at, ctladdr=ian (500/100), delay=00:00:04, xdelay=00:00:04, mailer=esmtp, pri=124637, relay=arachne.luga.at. [143.130.20.2], dsn=2.0.0, stat=Sent (Queued!) |
S.o. Alle weiteren Mails mit dem selben Absender an luga@luga.at werden sofort angenommen, es sei denn, der Server wechselt die IP-Adresse oder es kommen ein Monat lang keine Mails. Dann beginnt das Spiel von vorne.
Erfahrungen
Das Spam-Level ist deutlich zurückgegangen. Waren im Juli noch über 80% (137/166) der Mails an office Spam, so sind in der ersten Septemberhälfte nur noch 2 Spams eingelangt (dafür waren die vielen Virenwarnungen lästig).
Die Abbildung zeigt die tägliche Verteilung der SMTP-Connections. Die Zustände "DENYSOFT und "timed out" führen zu einem temporären Fehler, "is white" und "updated grey->white" zu einer Annahme der Mail. Die extrem hohe Zahl von gewhitelisteten Connections in den ersten 14 Tagen stammt von einem Sobig.F-Virus, der uns von einem einzigen Rechner aus mit Connections bombardiert hat, aber auf Grund eines Protokollfehlers nie fähig war, sich selbst zu verschicken. Man sieht aber, dass Greylisting gegen Viren und Würmer nur eingeschränkt hilft: Wenn viele Mails vom gleichen Absender kommen, werden sie durchgelassen (Immerhin verringert das die Anzahl der Absender ganz erheblich, und man kann diese dann leichter in Blacklisten aufnehmen).
Die beide Abbildungen zeigen die Zeit vom ersten Auftreten eines Keys bis zum Eintrag in die Whitelist, als Histogramm und kumulativ. Deutlich erkennbar ist die Spitze bei einer Stunde, die vom blacklist_timeout von 1 Stunde (mittlerweile auf 15 Minuten geändert) herrührt. Die Kurve fällt dann bis zum Ende des Greylist-Intervalls steil und relativ gleichmäßig ab. Soweit entspricht das den Erwartungen. Auffällig ist aber der extrem lange Schwanz mit einem weiteren Maximum bei ca. 3 Tagen. Ein Teil davon stammt sicher von Spam und Würmern, die es durch häufige Wiederholung irgendwann doch schaffen, in die Whitelist zu kommen. Ein Teil aber ist auf das Chello-Problem zurückzuführen.
Diese Abbildung zeigt die Verteilung der Idle-Zeiten vor einem erneuten Zustellversuch nach der Greylist-Periode. Sie sollte uns eigentlich helfen, typische Queue-Intervalle herauszufinden, aber abgesehen von einem 4-Stundenintervall ist nicht viel zu erkennen, da das Plateau bis zu ca. 2 Tagen fast flach ist. Das wird möglicherweise besser, sobald die Sobig-Einträge aus der Statistik rausfallen.
Das Chello-Problem
Chello verwendet mehrere Mailserver zum Versenden der Mail, wobei aufeinanderfolgende Zustellversuche der derselben Mail i.A. nicht vom gleichen Mailserver kommen, sondern von einem (zufällig gewählten?) anderen. Zusätzlich scheint es kein fixes Queue-Intervall zu geben. Der nächste Zustellversuch kann nach 1-2 Stunden kommen, nach 9 Stunden oder gar erst nach mehreren Tagen. Somit ist es für Chello-User reines Glücksspiel, ob und wann ihre Mail angenommen wird.