[LUGA] Mit freundlicher Unterstützung von:
WSR

Greylisting

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:16midori 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:5920164denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at initial DENYSOFT, unknown
2003-08-28T00:34:5920164450 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:31midori 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:1420214denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at black DENYSOFT - 1 failed connections
2003-08-28T00:47:1420214450 This mail is temporarily denied

Die Kombination ist jetzt bekannt, aber in der Blacklist. Noch ein Deny.

Aug 28 01:17:31midori 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:1520446denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at black DENYSOFT - 2 failed connections
2003-08-28T01:17:1520446450 This mail is temporarily denied
Aug 28 01:47:32midori 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:1520620denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at updated grey->white
2003-08-28T01:47:1520620running 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:15midori 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:0126859denysoft_greylist plugin: key 1.2.178.70:ian@midori.beispiel.at:luga@luga.at is white, 2 deliveries
2003-08-28T12:59:0126859250 luga@luga.at, recipient ok

Die Kombination ist bekannt, daher wird die Mail sofort angenommen.

Aug 28 18:05:05midori 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).

States per day

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

Zeit bis zum Eintrag in die Whitelist
	(Histogramm) Zeit bis zum Eintrag in die Whitelist
	(kumulativ)

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.

Idletime vor einem Timeout

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.


powered by LINUX the choice of a gnu generation
linux user group austria;
Suche
Suche
Letzte Änderung:
webmaster@luga.at
Februar 2011