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.

-- 
Mit besten Grüßen
Joachim Fahrner

PGP-Key: http://www.fahrner.name/JoachimFahrner.asc
---------------------------------------------------
Es gibt keine Cloud, es ist nur der Computer eines anderen