Re: Verständnisproblem access restrictions

[Joachim Fahrner]

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