Verständnisproblem access restrictions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Verständnisproblem access restrictions

J. Fahrner
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?

Gruss
Jochen

Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

Marco Dickert-2
Hallo Joachim,

On 2017-03-20 09:53:29, Joachim Fahrner wrote:
> 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?

Da gibt es gespaltene Meinungen. Ich habe gehört [1], dass Peer Heinlein
empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen und
den Rest leer zu lassen. Als versierter Postfix-Admin ist das sicherlich ein
gangbarer Weg. Der Abschnitt "Dangerous use of smtpd_recipient_restrictions" [2] in
dem von dir erwähnten Dokument beschreibt jedoch, dass die exklusive Verwendung
der Direktive zu einem Setup führen kann, welches zu freizügig ist. Das
verwendete Beispiel sollte die Situation etwas klarer machen.

Rein technisch ist es also IMHO egal, wie du das Setup aufbaust. Ich selbst habe
mich für eine Aufteilung der verschiedenen Restrictions auf die Direktiven
entschieden, erstens der Übersichtlichkeit halber, und um logische Fehler zu
vermeiden.

Viele Grüße,
Marco Dickert

[1] https://forum.ubuntuusers.de/topic/postfix-smtpd-relay-restrictions/#post-8770793
[2] http://www.postfix.org/SMTPD_ACCESS_README.html#danger
--
Marco Dickert
[hidden email]
https://misterunknown.de

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

Patrick Ben Koetter-2
In reply to this post by J. Fahrner
* Joachim Fahrner <[hidden email]>:

> 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


--
[*] 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
 
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

J. 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
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

Robert Schetterer-2
In reply to this post by Marco Dickert-2
Am 20.03.2017 um 11:04 schrieb Marco Dickert:
> dass Peer Heinlein
> empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen

finde ich unuebersichtlich, aber vermutlich koennte man auch genau
andersrum argumentieren


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://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
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

Robert Schetterer-2
In reply to this post by J. Fahrner
Am 20.03.2017 um 14:57 schrieb Joachim Fahrner:
> Mit Postscreen habe ich mittlerweile ein kleines Problem: wenn ich darin
> aggressive Blacklisten verwende (z.B. Sorbs),

ja das ist gelinde gesagt exotisch

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.

ich nutze nur zen.spamhaus in postscreen
Whitelist brauchts real immer

ein Vorteil der
restrictions

ist dass du relativ billig zusaetzlich selectiv separieren kannst

https://sys4.de/de/blog/2013/10/09/selektive-rbl-spf-greylisting-checks-mit-smtpd_restriction_classes/

so waere es evtl sogar vertretbar sorbs zu nutzen

Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://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
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

J. Fahrner
In reply to this post by Robert Schetterer-2
Am 20.03.2017 um 19:17 schrieb Robert Schetterer:
> Am 20.03.2017 um 11:04 schrieb Marco Dickert:
>> dass Peer Heinlein
>> empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen
> finde ich unuebersichtlich, aber vermutlich koennte man auch genau
> andersrum argumentieren
>

Stimmt schon, übersichtlicher ist es wenn man es trennt. Aber leider
müssen dann viele Prüfungen redundant durchgeführt werden. Ich habe z.B.
eine access-Liste mit Ausnahmen, die müsste ich dann zu jedem Zeitpunkt
immer wieder prüfen. Ich hab das jetzt mal alles unter
recipient_restrictions zusammengeführt, aber per Kommentarzeile nach den
zeitpunkten getrennt. So bleibt die Übersicht erhalten.
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

Robert Schetterer-2
Am 20.03.2017 um 19:25 schrieb J. Fahrner:

> Am 20.03.2017 um 19:17 schrieb Robert Schetterer:
>> Am 20.03.2017 um 11:04 schrieb Marco Dickert:
>>> dass Peer Heinlein
>>> empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu packen
>> finde ich unuebersichtlich, aber vermutlich koennte man auch genau
>> andersrum argumentieren
>>
>
> Stimmt schon, übersichtlicher ist es wenn man es trennt. Aber leider
> müssen dann viele Prüfungen redundant durchgeführt werden. Ich habe z.B.
> eine access-Liste mit Ausnahmen, die müsste ich dann zu jedem Zeitpunkt
> immer wieder prüfen. Ich hab das jetzt mal alles unter
> recipient_restrictions zusammengeführt, aber per Kommentarzeile nach den
> zeitpunkten getrennt. So bleibt die Übersicht erhalten.
>

kannst du machen ist nicht unbedingt falsch, ich nutze haeufig
Kombinationen aus seperaten und kombinierten whitelists
oft waechst sowas ja auch historisch, real laufen setups ja manchmal
Jahre, im Betrieb aendert man dann eher weniger , wenn man dann einen
neuen Server aufsetzt baut man dann Neuerungen ein die sich woanders
schon bewaehrt haben. Allerdings ist es wirklich nicht mehr leicht immer
up2date zu sein



Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://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
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

Patrick Ben Koetter-2
In reply to this post by J. Fahrner
* Joachim Fahrner <[hidden email]>:

> 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@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
 
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

J. Fahrner
Hallo Patrick,

Am 2017-03-21 21:52, schrieb Patrick Ben Koetter:

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.

Klar, das Ziel soll sein, 100% Spam erkennen bei 0% false positives. Aber der Weg dahin ist lang und mühsam.
Ich habe mir ein Python-Script geschrieben, welches aus dem Log alle Rejects übersichtlich ausgibt. Das sieht dann so aus:

Mar 21 14:34:45 RELAY:   from=<[hidden email]> to=<[hidden email]> ip=64.20.227.134 USA
Mar 21 21:23:28 rbltrap: from=<[hidden email]> to=<[hidden email]> ip=128.199.181.9 Singapore

Nach Regeländerungen kontrolliere ich das ein paar Tage lang täglich, um zu sehen ob legitime Mails abgewiesen wurden. Das funktioniert natürlich nur, wenn ich die Absender-Info und das Land habe. Und das macht natürlich nur bei einem kleinen privaten Mailserver Sinn. Als Provider hat man natürlich keine Chance zu erkennen was fälschlicherweise geblockt wurde. Ein Provider würde auch nie so aggressiv vorgehen wie ich das tue. Das ist übrigens mit ein Hauptgrund, warum ich selber einen Mailserver betreibe. Mir bringt das nix wenn Spam in einen Spam-Ordner verschoben wird, den ich dann wieder regelmässig kontrollieren muss. Dann kann der Spam auch gleich in der Inbox landen, das macht keinen Unterschied. Spam muss zuverlässig abgewiesen werden, das kann ein Provider prinzipbedingt nicht in der Qualität leisten, weil jeder seiner Kunden andere Ansprüche hat.

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.

Dass Postscreen viel Last wegnimmt ist schon klar. Ich meinte was anderes: bringt smtpd_delay_reject=no lastmässig einen Vorteil? Die Prüfungen müssen ja sowieso alle durchgeführt werden (bis zur ersten Reject-Regel), zu welchem Zeitpunkt das gemacht wird macht keinen Unterschied. Wenn man Teile der Prüfungen schon früher macht (z.B. HELO Restrictions), dann spart man sich doch lediglich das zwischenspeichern der Daten aus den folgenden Schritten (also z.B. MAIL FROM und RECPT TO). Ich kann mir nicht vorstellen, dass das einen Gewinn bringt.

-- 
Mit besten Grüßen
Joachim Fahrner

PGP-Key: http://www.fahrner.name/JoachimFahrner.asc
---------------------------------------------------
Es gibt keine Cloud, es ist nur der Computer eines anderen
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

J. Fahrner
In reply to this post by Robert Schetterer-2
Am 2017-03-20 19:17, schrieb Robert Schetterer:
> Am 20.03.2017 um 11:04 schrieb Marco Dickert:
>> dass Peer Heinlein
>> empfiehlt, alle Restrictions in die smtpd_recipient_restrictions zu
>> packen
>
> finde ich unuebersichtlich, aber vermutlich koennte man auch genau
> andersrum argumentieren

Hallo Robert,
wahrscheinlich hast du Recht. Ich bin nochmal in mich gegangen, und es
ist wirklich sehr unübersichtlich, wenn alles unter
recipient_restrictions zusammengefasst wird. Ich bin gerade dabei meine
Regeln nochmal umzustrukturieren, alles sauber zu trennen wie es sich
gehört. Allerdings stehe ich jetzt vor einem Dilemma: einerseits soll
man da die "billigen" Regeln zuerst anwenden, und die "teuren" Regeln
zum Schluss. Am aufwendigsten sind die Blacklist-Abfragen
(reject_rbl_client), und die gehören zu den client_restrictions, würden
dann ja ganz zu Beginn, also noch vor den HELO Restrictions ausgeführt.
Einen Tod muss man wohl sterben. Da mein Familien-Server nicht sooo viel
Mails verarbeiten muss, werde ich wohl die Performance-Einbussen in Kauf
nehmen und die Regeln lieber sauber trennen. Ich glaube das macht es
einfacher wartbar und weniger fehleranfällig. Zudem nimmt postscreen ja
schon viel Last vom smtpd Server.

Jochen


Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

J. Fahrner
Am 2017-03-27 07:40, schrieb Joachim Fahrner:
> Ich bin gerade dabei
> meine Regeln nochmal umzustrukturieren, alles sauber zu trennen wie es
> sich gehört.

Mist, das wird schwieriger als gedacht. Nach dem Buch "Postfix" von Ralf
und Patrick soll man ja die "role accounts" niemals blocken. D.h. diese
Prüfung muss vor die Blacklistabfragen. Packt man die in die client
restrictions (wo sie logisch ja hingehören) ist der Empfänger aber noch
nicht bekannt.

Jochen
Reply | Threaded
Open this post in threaded view
|

Re: Verständnisproblem access restrictions

Robert Schetterer-2
Am 27.03.2017 um 07:54 schrieb Joachim Fahrner:

> Am 2017-03-27 07:40, schrieb Joachim Fahrner:
>> Ich bin gerade dabei
>> meine Regeln nochmal umzustrukturieren, alles sauber zu trennen wie es
>> sich gehört.
>
> Mist, das wird schwieriger als gedacht. Nach dem Buch "Postfix" von Ralf
> und Patrick soll man ja die "role accounts" niemals blocken. D.h. diese
> Prüfung muss vor die Blacklistabfragen. Packt man die in die client
> restrictions (wo sie logisch ja hingehören) ist der Empfänger aber noch
> nicht bekannt.
>
> Jochen

das stimmt, wenn man allerdings die rbls sparsam verwendet
ist das kein grosses Problem, du kannst ja eh nichts dagegen tun wenn
jemand bei spamhaus gelistet ist ,diese Info bekommt der Absender ja in
jedem Fall bei der Ablehnung , es ist also Sache des Absenders von den
rbls runter zu kommen, das gilt auch dann wenn er zu postmaster senden will.
Fuer diesen Fall konnte man auch zusaetzlich eine Website anbieten
mit einem script zum Einliefern fuer Support Mails, oder einer
alternative Adresse bei einem anderen Anbieter.
An sich ist eine so eine Website immer eine gute Idee , Nachteil ist
eigentlich nur dass man sich zusaetzlich um einen Webserver kuemmern muss.


Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://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
Aufsichtsratsvorsitzender: Florian Kirstein