Hallo Patrick,
Am 2017-03-21 21:52, schrieb Patrick Ben Koetter:
Wenn Du Buch darüber führen musst, wer wann an wen senden wollte kannst Du das tun. Wenn Du aber im Anschluss daran rejectest erfährst Du das möglichweise (auch) nicht.
Ich persönlich investiere lieber in gute Filter mit geringen/kaum vorhandenen Falsch-Positiven. Klingt ein wenig arrogant, ist aber nicht meine Absicht. Ich strenge mich einfach lieber Für als Gegen etwas an. Und Buchführen über rejects ist IMO in der Regel in die "falsche Seite" investiert.
Klar, das Ziel soll sein, 100% Spam erkennen bei 0% false positives. Aber der Weg dahin ist lang und mühsam. Ich habe mir ein Python-Script geschrieben, welches aus dem Log alle Rejects übersichtlich ausgibt. Das sieht dann so aus:
Mar 21 14:34:45 RELAY: from=supertool@mxtoolbox.com to=test@example.com ip=64.20.227.134 USA Mar 21 21:23:28 rbltrap: from=lucy@topbananateam.com to=jf@fahrner.name ip=128.199.181.9 Singapore
Nach Regeländerungen kontrolliere ich das ein paar Tage lang täglich, um zu sehen ob legitime Mails abgewiesen wurden. Das funktioniert natürlich nur, wenn ich die Absender-Info und das Land habe. Und das macht natürlich nur bei einem kleinen privaten Mailserver Sinn. Als Provider hat man natürlich keine Chance zu erkennen was fälschlicherweise geblockt wurde. Ein Provider würde auch nie so aggressiv vorgehen wie ich das tue. Das ist übrigens mit ein Hauptgrund, warum ich selber einen Mailserver betreibe. Mir bringt das nix wenn Spam in einen Spam-Ordner verschoben wird, den ich dann wieder regelmässig kontrollieren muss. Dann kann der Spam auch gleich in der Inbox landen, das macht keinen Unterschied. Spam muss zuverlässig abgewiesen werden, das kann ein Provider prinzipbedingt nicht in der Qualität leisten, weil jeder seiner Kunden andere Ansprüche hat.
Die Filter im smtpd-Server können fies sein, aber das ist nicht der Punkt, denn sie müssen es nicht. Der postscreen dient vielmehr dazu, den Dienst "SMTP" verfügbar zu halten. Er schützt den Server vor einer Sättigung der smtpd-Server.
Dass Postscreen viel Last wegnimmt ist schon klar. Ich meinte was anderes: bringt smtpd_delay_reject=no lastmässig einen Vorteil? Die Prüfungen müssen ja sowieso alle durchgeführt werden (bis zur ersten Reject-Regel), zu welchem Zeitpunkt das gemacht wird macht keinen Unterschied. Wenn man Teile der Prüfungen schon früher macht (z.B. HELO Restrictions), dann spart man sich doch lediglich das zwischenspeichern der Daten aus den folgenden Schritten (also z.B. MAIL FROM und RECPT TO). Ich kann mir nicht vorstellen, dass das einen Gewinn bringt.