Verständnisproblem access restrictions

[Patrick Ben Koetter]

* Joachim Fahrner <jf at 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 at rick

P.S.
Zum Kopieren von Konfigurationen fällt mir Folgendes ein:
http://geek-and-poke.com/geekandpoke/2016/11/27/good-questions


-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein