Verständnisproblem access restrictions

[Patrick Ben Koetter]

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


-- 
[*] 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