Verständnisproblem access restrictions
Hallo Liste, ich habe jetzt die Seite http://www.postfix.org/SMTPD_ACCESS_README.html gefühlte 100 mal durchgelesen, aber immer noch ein Verständnisproblem damit.
Ursprünglich wurden die unterschiedlichen Prüfungen zu unterschiedlichen Zeitpunkten gemacht. Heute werden die jedoch zurückgehalten bis zum Zeitpunkt "RCPT TO" oder "ETRN". Welchen Sinn macht dann die Trennung nach Zeitpunkten überhaupt noch? Dann könnte man doch gleich alles in smtpd_recipient_restrictions reinpacken, und bräuchte die anderen restrictions nicht mehr. So muss man nur einige Prüfungen mehrfach wiederholen (z.B. permit_mynetworks). Ich finde das ziemlich verwirrend, und weiß nie wann welche Prüfung wo reingehört, und welche permits ich davor benötige. Das führt dazu, dass man sich immer an irgendwelchen Beispielen aus dem Netz orientiert, die dann oft für irgendwelche uralt-Versionen gemacht sind, oder wo auch nur einer woanders abgeschrieben hat, ohne es wirklich verstanden zu haben.
Kann das jemand mit einfachen Worten erklären?
Gruss Jochen
Hallo Joachim,
On 2017-03-20 09:53:29, Joachim Fahrner wrote:
Ursprünglich wurden die unterschiedlichen Prüfungen zu unterschiedlichen Zeitpunkten gemacht. Heute werden die jedoch zurückgehalten bis zum Zeitpunkt "RCPT TO" oder "ETRN". Welchen Sinn macht dann die Trennung nach Zeitpunkten überhaupt noch?
Da gibt es gespaltene Meinungen. Ich habe gehört [1], dass Peer Heinlein empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen und den Rest leer zu lassen. Als versierter Postfix-Admin ist das sicherlich ein gangbarer Weg. Der Abschnitt "Dangerous use of smtpd_recipient_restrictions" [2] in dem von dir erwähnten Dokument beschreibt jedoch, dass die exklusive Verwendung der Direktive zu einem Setup führen kann, welches zu freizügig ist. Das verwendete Beispiel sollte die Situation etwas klarer machen.
Rein technisch ist es also IMHO egal, wie du das Setup aufbaust. Ich selbst habe mich für eine Aufteilung der verschiedenen Restrictions auf die Direktiven entschieden, erstens der Übersichtlichkeit halber, und um logische Fehler zu vermeiden.
Viele Grüße, Marco Dickert
[1] https://forum.ubuntuusers.de/topic/postfix-smtpd-relay-restrictions/#post-87... [2] http://www.postfix.org/SMTPD_ACCESS_README.html#danger
Am 20.03.2017 um 11:04 schrieb Marco Dickert:
dass Peer Heinlein empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen
finde ich unuebersichtlich, aber vermutlich koennte man auch genau andersrum argumentieren
Best Regards MfG Robert Schetterer
Am 20.03.2017 um 19:17 schrieb Robert Schetterer:
Am 20.03.2017 um 11:04 schrieb Marco Dickert:
dass Peer Heinlein empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen
finde ich unuebersichtlich, aber vermutlich koennte man auch genau andersrum argumentieren
Stimmt schon, übersichtlicher ist es wenn man es trennt. Aber leider müssen dann viele Prüfungen redundant durchgeführt werden. Ich habe z.B. eine access-Liste mit Ausnahmen, die müsste ich dann zu jedem Zeitpunkt immer wieder prüfen. Ich hab das jetzt mal alles unter recipient_restrictions zusammengeführt, aber per Kommentarzeile nach den zeitpunkten getrennt. So bleibt die Übersicht erhalten.
Am 20.03.2017 um 19:25 schrieb J. Fahrner:
Am 20.03.2017 um 19:17 schrieb Robert Schetterer:
Am 20.03.2017 um 11:04 schrieb Marco Dickert:
dass Peer Heinlein empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen
finde ich unuebersichtlich, aber vermutlich koennte man auch genau andersrum argumentieren
Stimmt schon, übersichtlicher ist es wenn man es trennt. Aber leider müssen dann viele Prüfungen redundant durchgeführt werden. Ich habe z.B. eine access-Liste mit Ausnahmen, die müsste ich dann zu jedem Zeitpunkt immer wieder prüfen. Ich hab das jetzt mal alles unter recipient_restrictions zusammengeführt, aber per Kommentarzeile nach den zeitpunkten getrennt. So bleibt die Übersicht erhalten.
kannst du machen ist nicht unbedingt falsch, ich nutze haeufig Kombinationen aus seperaten und kombinierten whitelists oft waechst sowas ja auch historisch, real laufen setups ja manchmal Jahre, im Betrieb aendert man dann eher weniger , wenn man dann einen neuen Server aufsetzt baut man dann Neuerungen ein die sich woanders schon bewaehrt haben. Allerdings ist es wirklich nicht mehr leicht immer up2date zu sein
Best Regards MfG Robert Schetterer
Am 2017-03-20 19:17, schrieb Robert Schetterer:
Am 20.03.2017 um 11:04 schrieb Marco Dickert:
dass Peer Heinlein empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen
finde ich unuebersichtlich, aber vermutlich koennte man auch genau andersrum argumentieren
Hallo Robert, wahrscheinlich hast du Recht. Ich bin nochmal in mich gegangen, und es ist wirklich sehr unübersichtlich, wenn alles unter recipient_restrictions zusammengefasst wird. Ich bin gerade dabei meine Regeln nochmal umzustrukturieren, alles sauber zu trennen wie es sich gehört. Allerdings stehe ich jetzt vor einem Dilemma: einerseits soll man da die "billigen" Regeln zuerst anwenden, und die "teuren" Regeln zum Schluss. Am aufwendigsten sind die Blacklist-Abfragen (reject_rbl_client), und die gehören zu den client_restrictions, würden dann ja ganz zu Beginn, also noch vor den HELO Restrictions ausgeführt. Einen Tod muss man wohl sterben. Da mein Familien-Server nicht sooo viel Mails verarbeiten muss, werde ich wohl die Performance-Einbussen in Kauf nehmen und die Regeln lieber sauber trennen. Ich glaube das macht es einfacher wartbar und weniger fehleranfällig. Zudem nimmt postscreen ja schon viel Last vom smtpd Server.
Jochen
Am 2017-03-27 07:40, schrieb Joachim Fahrner:
Ich bin gerade dabei meine Regeln nochmal umzustrukturieren, alles sauber zu trennen wie es sich gehört.
Mist, das wird schwieriger als gedacht. Nach dem Buch "Postfix" von Ralf und Patrick soll man ja die "role accounts" niemals blocken. D.h. diese Prüfung muss vor die Blacklistabfragen. Packt man die in die client restrictions (wo sie logisch ja hingehören) ist der Empfänger aber noch nicht bekannt.
Jochen
Am 27.03.2017 um 07:54 schrieb Joachim Fahrner:
Am 2017-03-27 07:40, schrieb Joachim Fahrner:
Ich bin gerade dabei meine Regeln nochmal umzustrukturieren, alles sauber zu trennen wie es sich gehört.
Mist, das wird schwieriger als gedacht. Nach dem Buch "Postfix" von Ralf und Patrick soll man ja die "role accounts" niemals blocken. D.h. diese Prüfung muss vor die Blacklistabfragen. Packt man die in die client restrictions (wo sie logisch ja hingehören) ist der Empfänger aber noch nicht bekannt.
Jochen
das stimmt, wenn man allerdings die rbls sparsam verwendet ist das kein grosses Problem, du kannst ja eh nichts dagegen tun wenn jemand bei spamhaus gelistet ist ,diese Info bekommt der Absender ja in jedem Fall bei der Ablehnung , es ist also Sache des Absenders von den rbls runter zu kommen, das gilt auch dann wenn er zu postmaster senden will. Fuer diesen Fall konnte man auch zusaetzlich eine Website anbieten mit einem script zum Einliefern fuer Support Mails, oder einer alternative Adresse bei einem anderen Anbieter. An sich ist eine so eine Website immer eine gute Idee , Nachteil ist eigentlich nur dass man sich zusaetzlich um einen Webserver kuemmern muss.
Best Regards MfG Robert Schetterer
* Joachim Fahrner jf@fahrner.name:
Hallo Liste, ich habe jetzt die Seite http://www.postfix.org/SMTPD_ACCESS_README.html gefühlte 100 mal durchgelesen, aber immer noch ein Verständnisproblem damit.
Ursprünglich wurden die unterschiedlichen Prüfungen zu unterschiedlichen Zeitpunkten gemacht. Heute werden die jedoch zurückgehalten bis zum Zeitpunkt "RCPT TO" oder "ETRN". Welchen Sinn macht dann die Trennung nach Zeitpunkten überhaupt noch? Dann könnte man doch gleich alles in smtpd_recipient_restrictions reinpacken, und bräuchte die anderen restrictions nicht mehr. So muss man nur einige Prüfungen mehrfach wiederholen (z.B. permit_mynetworks). Ich finde das ziemlich verwirrend, und weiß nie wann welche Prüfung wo reingehört, und welche permits ich davor benötige. Das führt dazu, dass man sich immer an irgendwelchen Beispielen aus dem Netz orientiert, die dann oft für irgendwelche uralt-Versionen gemacht sind, oder wo auch nur einer woanders abgeschrieben hat, ohne es wirklich verstanden zu haben.
Kann das jemand mit einfachen Worten erklären?
Laut RFC muss ein SMTP-Client zu jedem Zeitpunkt die Session mit dem Server beenden, wenn dieser das wünscht. An dieses RFC halten sich manche Clients nicht.
Deshalb wird der Moment, zu dem der Postfix smtpd-Server REJECT (lies: "Ich wünsche das Ende der Session") sagt, bis zu dem Moment verzögert an dem der Client den (ersten) Recipient gesendet hat.
Diese Funktion wurde nachträglich hinzugefügt. Sie wird über den Parameter smtpd_delay_reject gesteuert. Per default ist er auf "yes" gesetzt. Der REJECT wird so erst nach dem (ersten) Recipient gesendet.
Für lange Zeit gab es keinen Grund an diesem Setup zu rütteln, denn alle - MTAs und Desktop-Clients (MUA) - sendeten über Port 25 an den Server. Und weil ohnehin alle restrictions erst zum Zeitpunkt des ersten Recipient effektiv wurden, einigte man sich darauf sie alle auch erst in smtpd_recipient_restrictions auswerten zu lassen. Folglich war es best practice, alle restrictions in die smtpd_recipient_restrictions zu schreiben und alle anderen smtpd_*_restrictions gar nicht zu füllen.
Die Situation änderte sich mit der steigenden Popularität des submission-Ports 587 und auch als der postscreen-Daemon hinzukam. Über den Port war es möglich (fehlerhafte) Desktop-Client getrennt von den MTAs auf Port 25 zu behandeln.
Wer DNSBL im postscreen-Daemon einsetzt kommt nicht umhin, MUAs auf den submission-Port umzuziehen, denn viele MUAS wollen aus IP-Ranges connecten, die in DNSBL geblacklistet sind. Sie würden vom postscreen-Daemon abgelehnt noch bevor sie überhaupt in die Nähe eines ersten Recipient gekommen wären.
Wir haben mit dem postscreen-Daemon *sehr gute* Erfahrungen gemacht und trennen MUAs (587) von MTAs (25). Die Trennung gestattet uns auf dem Port 25 smtpd_delay_reject auf "no" zu setzen und so zu *jedem Zeitpunkt* MTAs zu REJECTEN, wenn unsere Filter das für nötig befinden.
So können wir früher und aggressiver abuse entgegentreten. Wir können Filter aktivieren, die bei MUAs viele Falsch-Positive hervorrufen würden, bei MTAs aber nicht. Dieser Ansatz schont die Systemressourcen und läßt auf Port 25 striktere Regeln zu, die besser vor abuse schützen.
Ein permit_mynetworks *muss* in den smtpd_recipient_restriction sein. Zu diesem Zeitpunkt gibt der Client bekannt an wen er senden will und (erst) dann kann Postfix entscheiden, ob die Nachricht
- von einem vertrauenswürdigen Netzwerk (mynetworks) gesendet werden soll oder - an einen Empfänger gehen soll, für den Postfix selbst zu ständig ist.
Wenn beides nicht gegeben ist, sendet ein Unvertrauter an jemanden für den der Server nicht zuständig ist. Das unterbindet er mit einem REJECT, denn er wäre sonst ein Open Relay.
Ob ein permit_mynetworks in den vorherigen Phasen der Session - CLIENT, HELO, MAIL FROM - oder anschliessend - DATA, END_OF_DATA - sinnvoll ist, musst Du ihm Rahmen Deiner konkreten Policy entscheiden.
Beispiel: Es könnte sinnvoll sein einen buggy MTA, der keinen korrekten HELO zustandebringt, über mynetworks und permit_mynetworks senden zu lassen. Ziemlich hypothetisch, denn ich würde das anders lösen, aber dann hätte ich jetzt kein Beispiel. ;)
HTH
p@rick
P.S. Zum Kopieren von Konfigurationen fällt mir Folgendes ein: http://geek-and-poke.com/geekandpoke/2016/11/27/good-questions
Hallo Patrick,
danke für die ausführliche und (glaube ich jedenfalls) verständliche Erklärung. Ich versuche mal daraus Schlüsse zu ziehen, korrigiere mich bitte wenn ich etwas falsch verstanden habe.
Am 2017-03-20 11:27, schrieb Patrick Ben Koetter:
Deshalb wird der Moment, zu dem der Postfix smtpd-Server REJECT (lies: "Ich wünsche das Ende der Session") sagt, bis zu dem Moment verzögert an dem der Client den (ersten) Recipient gesendet hat.
Ok, das war einer der Gründe. Ein anderer war, damit man im Log auch sieht von wem die Mail kam und an wen sie gehen sollte?
Folglich war es best practice, alle restrictions in die smtpd_recipient_restrictions zu schreiben und alle anderen smtpd_*_restrictions gar nicht zu füllen.
Ok, also gibt es keinen Grund die anderen restrictions zu füllen, wenn man den Reject ohnehin verzögert. Oder umgekehrt, die machen nur Sinn wenn man den Reject frühzeitig ausführen will.
Wir haben mit dem postscreen-Daemon *sehr gute* Erfahrungen gemacht und trennen MUAs (587) von MTAs (25). Die Trennung gestattet uns auf dem Port 25 smtpd_delay_reject auf "no" zu setzen und so zu *jedem Zeitpunkt* MTAs zu REJECTEN, wenn unsere Filter das für nötig befinden.
Postscreen und Port 587 nutze ich ebenfalls. Man verliert mit dem frühzeitigen Reject aber auch die Info von wem da was geblockt wurde. Kosten die Schritte vor dem RCPTTO wirklich soviel Resourcen, dass sich das lohnt? Solange in diesen Schritten noch keine Prüfungen stattfinden, muss Postfix sich doch eigentlich nur die gelieferte Information merken, bis zum finalen Schritt.
Mit Postscreen habe ich mittlerweile ein kleines Problem: wenn ich darin aggressive Blacklisten verwende (z.B. Sorbs), dann wird zuviel geblockt und ich habe an der Stelle keine Möglichkeit bestimmte Absender zu whitelisten. Das könnte ich nur bei den recipient_restrictions. Ich überlege gerade, ob es Sinn machen würde, bei postscreen nur weniger aggresive Blacklists einzutragen, und in recipient_restrcitions die aggressiveren, und davor eine whitelist.
Ein permit_mynetworks *muss* in den smtpd_recipient_restriction sein. Zu diesem Zeitpunkt gibt der Client bekannt an wen er senden will und (erst) dann kann Postfix entscheiden, ob die Nachricht
- von einem vertrauenswürdigen Netzwerk (mynetworks) gesendet werden
soll oder
- an einen Empfänger gehen soll, für den Postfix selbst zu ständig ist.
Wenn beides nicht gegeben ist, sendet ein Unvertrauter an jemanden für den der Server nicht zuständig ist. Das unterbindet er mit einem REJECT, denn er wäre sonst ein Open Relay.
Hmm, grübel... heisst das, die recipent_restriction wird auch auf dem Port 587 durchgeführt? Wenn ja, die anderen dann nicht? Wo ist der Unterschied zwischen 25 und 587 bei den restrictions? Wenn nein, warum muss dann permit_mynetworks drin sein? Und was ist mit lokalen Programmen (mailx, php), auf welchem Weg kippen die ihre Mails ein?
Ob ein permit_mynetworks in den vorherigen Phasen der Session - CLIENT, HELO, MAIL FROM - oder anschliessend - DATA, END_OF_DATA - sinnvoll ist, musst Du ihm Rahmen Deiner konkreten Policy entscheiden.
Wenn alle MUAs über 587 einkippen braucht's das nicht?
Gruss Jochen
Am 20.03.2017 um 14:57 schrieb Joachim Fahrner:
Mit Postscreen habe ich mittlerweile ein kleines Problem: wenn ich darin aggressive Blacklisten verwende (z.B. Sorbs),
ja das ist gelinde gesagt exotisch
dann wird zuviel geblockt
und ich habe an der Stelle keine Möglichkeit bestimmte Absender zu whitelisten. Das könnte ich nur bei den recipient_restrictions. Ich überlege gerade, ob es Sinn machen würde, bei postscreen nur weniger aggresive Blacklists einzutragen, und in recipient_restrcitions die aggressiveren, und davor eine whitelist.
ich nutze nur zen.spamhaus in postscreen Whitelist brauchts real immer
ein Vorteil der restrictions
ist dass du relativ billig zusaetzlich selectiv separieren kannst
https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-...
so waere es evtl sogar vertretbar sorbs zu nutzen
Best Regards MfG Robert Schetterer
* Joachim Fahrner jf@fahrner.name:
danke für die ausführliche und (glaube ich jedenfalls) verständliche Erklärung. Ich versuche mal daraus Schlüsse zu ziehen, korrigiere mich bitte wenn ich etwas falsch verstanden habe.
Am 2017-03-20 11:27, schrieb Patrick Ben Koetter:
Deshalb wird der Moment, zu dem der Postfix smtpd-Server REJECT (lies: "Ich wünsche das Ende der Session") sagt, bis zu dem Moment verzögert an dem der Client den (ersten) Recipient gesendet hat.
Ok, das war einer der Gründe. Ein anderer war, damit man im Log auch sieht von wem die Mail kam und an wen sie gehen sollte?
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.
Folglich war es best practice, alle restrictions in die smtpd_recipient_restrictions zu schreiben und alle anderen smtpd_*_restrictions gar nicht zu füllen.
Ok, also gibt es keinen Grund die anderen restrictions zu füllen, wenn man den Reject ohnehin verzögert.
ACK
Oder umgekehrt, die machen nur Sinn wenn man den Reject frühzeitig ausführen will.
ACK
Wir haben mit dem postscreen-Daemon *sehr gute* Erfahrungen gemacht und trennen MUAs (587) von MTAs (25). Die Trennung gestattet uns auf dem Port 25 smtpd_delay_reject auf "no" zu setzen und so zu *jedem Zeitpunkt* MTAs zu REJECTEN, wenn unsere Filter das für nötig befinden.
Postscreen und Port 587 nutze ich ebenfalls. Man verliert mit dem frühzeitigen Reject aber auch die Info von wem da was geblockt wurde. Kosten die Schritte vor dem RCPTTO wirklich soviel Resourcen, dass sich das lohnt?
Als Ralf und ich python.org Postmaster wurden, waren auf dem Server ca. 350 smtpd-Server-Prozesse in Betrieb, weil sehr viele Spammer versuchten E-Mail auf der Plattform einzuliefern. Die Last wuchs auf irgendwas um die 35 und Ralf und ich unterhielten uns darüber, neue leistungsfähigere Hardware anzufragen.
Dann stellte Wietse den ersten snapshot mit postscreen-Daemon vor. Ralf - auch gerne Mr. Unstable genannt - installierte den snapshot wenige Minuten später und wir nahmen den postscreen in Betrieb. Die Last fiel augenblicklich und nur wenige Tage später pegelten wir den smtpd in der master.cf auf die 80 Prozesse ein.
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.
Ähnliches habe ich seitdem vielfach auf kleinen wie auf (sehr) grossen Plattformen beobachtet. Aus diesem Grund setze ich ihn so gerne ein.
Solange in diesen Schritten noch keine Prüfungen stattfinden, muss Postfix sich doch eigentlich nur die gelieferte Information merken, bis zum finalen Schritt.
ACK
Mit Postscreen habe ich mittlerweile ein kleines Problem: wenn ich darin aggressive Blacklisten verwende (z.B. Sorbs), dann wird zuviel geblockt und ich habe an der Stelle keine Möglichkeit bestimmte Absender zu whitelisten.
Ich würde sorbs meiden. Zuviele Falsch-Positive.
Das könnte ich nur bei den recipient_restrictions. Ich überlege gerade, ob es Sinn machen würde, bei postscreen nur weniger aggresive Blacklists einzutragen, und in recipient_restrcitions die aggressiveren, und davor eine whitelist.
+1
Ein permit_mynetworks *muss* in den smtpd_recipient_restriction sein. Zu diesem Zeitpunkt gibt der Client bekannt an wen er senden will und (erst) dann kann Postfix entscheiden, ob die Nachricht
- von einem vertrauenswürdigen Netzwerk (mynetworks) gesendet werden
soll oder
- an einen Empfänger gehen soll, für den Postfix selbst zu ständig ist.
Wenn beides nicht gegeben ist, sendet ein Unvertrauter an jemanden für den der Server nicht zuständig ist. Das unterbindet er mit einem REJECT, denn er wäre sonst ein Open Relay.
Hmm, grübel... heisst das, die recipent_restriction wird auch auf dem Port 587 durchgeführt?
Wenn Du im submission-Service in der master.cf keine Angaben machst, die von denen in der main.cf abweichen, werden die dort beschriebenen, globalen Filter auch auf den submission Service angewendet.
Es sind *smtpd* _recipient_restrictions. Die in der main.cf niedergeschriebenen Regeln werden auf *jeden* smtpd-Prozess angewendet, ausser es wurde service-spezifisch in der master.cf Abweichendes notiert.
Um abweichende Filter-Policies einfacher zu setzen und auch um Abweichungen sichtbar zu machen, hatte ich vor ein paar Jahren angeregt submission_*_restrictions einzuführen. Wietse griff das auf und machte mua_*_restrictions daraus:
submission inet n - n - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_reject_unlisted_recipient=no -o smtpd_client_restrictions=$mua_client_restrictions -o smtpd_helo_restrictions=$mua_helo_restrictions -o smtpd_sender_restrictions=$mua_sender_restrictions -o smtpd_recipient_restrictions= -o smtpd_relay_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING
Wenn ja, die anderen dann nicht? Wo ist der Unterschied zwischen 25 und 587 bei den restrictions?
Das findest Du (nur) hostspezifisch raus, wenn Du die diversen Restrictions miteinander vergleichst.
Wenn nein, warum muss dann permit_mynetworks drin sein?
Auf 587? Aus meiner Sicht muss mindestens das hier sein:
-o smtpd_recipient_restrictions= reject_non_fqdn_sender reject_non_fqdn_recipient reject_unknown_sender_domain reject_unknown_recipient_domain permit_sasl_authenticated reject
Die ersten 4 Filter widmen sich ausschliesslich der Frage:
Kann ich diese Mail transportieren?
Warum? Der Submission-Service ist der Dienst über den Nachrichten den Transportweg betreten. Aufgabe des Submission-Service ist die Transportfähigkeit zu prüfen. Genau diese Aufgabe erfüllen die ersten 4 Filter.
Dann dürfen SMTP AUTH authentifzierte Accounts senden und gleich danach machen wir den Laden zu.
Mit diesem Regelsatz fange ich immer an. Je nach Plattform kommen dann noch Filter hinzu. Für ISPs bauen wir z.B. Dienste ein, die abuse automatisiert erkennen und blocken oder Kunden mit tempfails und passenden Texten daran erinnern, ihre Rechnung zu zahlen... ;)
Oder Statistik-Daten-Spender, die uns helfen, die Nutzung des Dienstes zu profilen. Auf Alt-Plattformen willst du vielleicht wissen wieviele Accounts sich (immer noch) ohne STARTTLS oder mit Shared-Secret Mechanismen anmelden.
Die willst Du anschreiben und auf sichere Pfade migrieren, damit die Smartphones dieser User deren Credentials nicht in offenen WLANs in unverschlüsselter Kommunikation preisgeben.
Und was ist mit lokalen Programmen (mailx, php), auf welchem Weg kippen die ihre Mails ein?
Die nutzen für gewöhnlich das sendmail-Kommando und unterliegen nicht den Beschränkungen des smtpd-Daemon, weil sie in die maildrop-Queue geworfen werden und dort vom pickup-Daemon in das Mailsystem gezogen werden.
Auf Hosting-Plattformen versuche ich immer durchzusetzen, das PHP-Skripte authentifiziert (!) über SMTP einliefern. Das erleichtert das limitieren *und* blocken immens *ohne* andere Kunden einzuschränken.
Ob ein permit_mynetworks in den vorherigen Phasen der Session - CLIENT, HELO, MAIL FROM - oder anschliessend - DATA, END_OF_DATA - sinnvoll ist, musst Du ihm Rahmen Deiner konkreten Policy entscheiden.
Wenn alle MUAs über 587 einkippen braucht's das nicht?
Das kann ich Dir so leider nicht einfach bejaen. Ob und wenn wo man Filter setzen muss, muss fallweise betrachtet werden.
p@rick
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.
participants (5)
-
J. Fahrner -
Joachim Fahrner
-
Marco Dickert -
Patrick Ben Koetter -
Robert Schetterer