[Postfixbuch-users] Spam-Abwehr durch Stottern

[Thomas Schwenski]

Guten Morgen Liste,

hat zufälligerweise jemand den Artikel "Schneckenpost" im aktuellen 
Linuxmagazin (Heft 02/08 Seite 74) gelesen?
Dort wird eine Technik als Nachfolger von Greylisting beschrieben um 
spammende Mailserver "abzuweisen".

Kern der Technik ist, dass man mit validen Mailservern eine Teergrube 
simuliert.
D.h. der eigentlich valide Mailserver verzögert zu Beginn der 
Kommunikation seine Antworten eine Zeit lang und stottert so.

Der Mailserver (oder die SMTP-Engine des von den Spammern verwendeten 
Botnetzes) erhält dadurch den Eindruck, dass es sich beim Ziel-MX um 
eine Teergrube handelt und bricht (eine gewisse Intelligenz der Software 
  vorrausgesetzt) die Kommunikation ab.
Nach einer festgelegten Anzahl übermittelter Bytes kommunziert der 
empfangende Mailserver normal schnell.
Sinnvollerweise sollte es sich bei diesem Zählwert aber um einen 
Zufallswert handeln, der lediglich durch eine Obergrenze bestimtm ist.

Hintergrund dieser Technik ist die Wirtschaftlichkeit des 
Nachrichtenversandes für Spammer. Eine Teergrube verursacht nur Kosten 
hat aber keinen oder nur wenig Nutzen, da lediglich Ressourcen für die 
Zeit des Kommunikationsversuches gebunden werden.

Im Artikel wird unser aller "Lieblingsmailserverdienst" sendmail 
dahingehend verändert um entsprechend zu agieren.

Bei lesen fiel mir nur folgende Möglichkeit einer Umsetzung für Postfix ein:
Die Einbindung erfolgt über die Policy-Schnittstelle, ein entsprechender 
Dienst wird in die smtpd_(helo|sender|recipient|data)_restrictions 
eingebunden und ist somit in jeder Phase der SMTP-Kommunikation präsent.
In jeder dieser Ebenen verzögert der Policy-Daemon seine Antwort um eine 
zufällige Anzahl von Sekunden.
Anhand der Queue-ID kann er Buch führen, wieviele Sekunden die 
Nachrichtenannahme bereits verzögert wurde.

Um die entsprechende Datenbank nicht zu sehr wachsen zu lassen, könnte 
man in der letzten Ebene in der der Dienst eingebunden ist dann den 
Datensatz dann löschen.
(Alternativ über die Einbindung in den smtpd_end_of_data_restrictions, 
aber dann wird eine neue Policy-Abfrage nötig -> unnötige 
Ressourcenver(sch)wendung.)

Idealerweise übernimmt der Dämon dann auch noch auf der 
smtpd_recipient_restrictions-Ebene die Greylisting-Funktionalität.

Wie seht Ihr das?
Wäre das eine Erweiterung/Nachfolge für Greylisting??

Gruß
Thomas