* 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