* Tobias Koopmann tobias@koopmann-mail.de:

Macht es also Sinn wenn man postscreen mit deep_protocol_tests einsetzt auf z.B. postgrey zu verzichten, wie sieht ihr das?

Ich setze für meine Account p@state-of-mind.de nur postscreen ein und verzichte auf Greylisting. Gemessen habe ich noch nicht, aber gefühlt habe ich genauso viel/wenig Spam wie vorher. Mails kommen aber schneller an. Das ist schön, denn genau das Delay hat mich an Greylisting schon immer gestört. :)

p@rick

Zitat von Tobias Koopmann tobias@koopmann-mail.de:

Hallo Liste,

nachdem ich mich ein wenig in postscreen eingelesen habe, stellt sich mich die Frage, ob es sinnvoll ist zusätzlich zu postscreen noch greylisting zu fahren.

Postscreen zumindest mit den deep_protocol_tests kann nach erfolgreichen Tests die Verbindung nicht an den smtpd weitergeben und weist den client mit nem 4xxer Code ab. Also für mein Verständnis auch eine Art von Greylist, dessen Entscheidung meiner Meinung nach auf besseren Prüfungen beruht als der des Triplets beim greylisting.

Macht es also Sinn wenn man postscreen mit deep_protocol_tests einsetzt auf z.B. postgrey zu verzichten, wie sieht ihr das?

Ist ähnlich aber nicht gleich. Postscreen testet ob das SMTP Protokoll eingehalten wird und falls ja lässt den nächsten Versuch passieren *unabhängig* davon wann der nächste Versuch auftritt. Greylisting arbeitet üblicherweise nur zeitbasiert d.h. unabhängig davon ob das Protokoll eingehalten wird, wird die Verbindung erst nach einer gewissen Zeit weiter gereicht.

Postscreen ist wirkungslos gegen Bots die das Protokoll einhalten und Greylisting ist wirkungslos gegen Sender die über einen längeren Zeitraum Retrys machen.

Gruß

Andreas

Hallo,

angeregt durch den Artikel im Linux-Magazin 08/11 spiele ich grade mit Postscreen auf einem Testserver (Debian Squeeze mit Postfix aus Squeeze Backports) rum.

On Thu, Jun 30, 2011 at 08:49:40AM +0200, Tobias Koopmann wrote:

nachdem ich mich ein wenig in postscreen eingelesen habe, stellt sich mich die Frage, ob es sinnvoll ist zusätzlich zu postscreen noch greylisting zu fahren.

Das habe ich mich auch erstmal gefragt.

Postscreen zumindest mit den deep_protocol_tests kann nach erfolgreichen Tests die Verbindung nicht an den smtpd weitergeben und weist den client mit nem 4xxer Code ab.

Soweit ich die Doku unter http://www.postfix.org/postconf.5.html#postscreen_bare_newline_enable verstehe gilt dies nicht für den Bare Newline Test. Dieser bricht die Verbindung danach _immer_ mit einem 450er ab, egal ob der Test bestanden wurde oder nicht. Wie er sich verhält falls der Test nicht bestanden wurde, hängt dann von postscreen_bare_newline_action ab.

Schön nachvollziehen kann man das mit folgenden (nicht für die Praxis gedachten :-) Settings:

postscreen_bare_newline_enable = yes postscreen_bare_newline_action = drop postscreen_bare_newline_ttl = 1s

Geht man mit Telnet auf Port 25, sendet es immer "richtige" Newlines. Also habe ich nc (netcat) genommen und das HELO mal nur mit Ctrl-M und mal nur mit Ctrl-J beendet. Und bin wie erwartet sofort mit "521 5.5.1 Protocol error" rausgeflogen.

Wenn ich dann aber mit swaks[1] teste (das definitiv korrekte Newlines schickt und ja auch nicht sofort rausfliegt), kommt immer der 450er. Sobald ich aber "postscreen_bare_newline_enable = no" setze, kommt swaks wieder durch und kann Mails versenden.

[1] http://www.jetmore.org/john/code/swaks/

Was ich aber nicht verstehe: Warum endet der Bare Newline Test immer mit einem 450er? Gibt es irgendeinen logischen Grund dafür? (Der sich mir dann aber momentan nicht erschließt. ;-) Oder ist das momentan einfach eine Einschränkung in der Implementation?

Also für mein Verständnis auch eine Art von Greylist, dessen Entscheidung meiner Meinung nach auf besseren Prüfungen beruht als der des Triplets beim greylisting.

Wie die meisten anderen Antworten schon zeigten, gibt es einige Unterschiede zum Greylisting, die es nicht zum vollständigen Ersatz im Sinne des Greylistings machen.

Mit freundlichem Gruss, Axel Beckert