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