* 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