Re: Verständnisproblem access restrictions

[Joachim Fahrner]

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 at mxtoolbox.com>
to=<test at example.com> ip=64.20.227.134 USA
Mar 21 21:23:28 rbltrap: from=<lucy at topbananateam.com>
to=<jf at 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
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://de.postfix.org/pipermail/postfix-users/attachments/20170322/0cb2ab06/attachment.html>