restrictions einbauen

[Sebastian Gödecke]

Am Do., 26. Sept. 2019 um 12:35 Uhr schrieb Kai Fürstenberg
<kai_postfix at fuerstenberg.ws>:
>
> Hallo Sebastian,
>
> Am 26.09.2019 um 11:31 schrieb Sebastian Gödecke:
> > Hallo ML,
> > ich möchte unseren Postfix weiter absichern. Wir betreiben den im
> > Rahmen einer Schule.
> > Was in letzter Zeit vorgekommen ist, sind das Versenden von Mails die
> > wohl als spam klassifiziert werden können. Auch das unauthorisierte
> > Versenden soll nicht erlaubt sein.
> > Ich gehe davon aus, das mit den restrictions in der main.cf zu machen.
> > Was kann ich als Optionen noch setzen, damit das Mailen nur von
> > autorisierten, also kein Massenversand durch irgend wen, Personen
> > erfolgen kann.
> > Des weiteren überlege ich, den Port zum Versenden (von kollegen mit
> > ihren mobilen Geräten, aktuell 587) nur noch über einen high-port zu
> > erlauben. Von aussen wäre das über einen Portweiterleitung, von innen
> > muss ich in der master.cf etwas ändern. Wo muss ich da etwas ändern?
> > Danke für tipps.
> >
> > Hier meine Configs:
>
> Ich habe mir momentan mal nur die Restriktionen angesehen. Da ist zwar
> im Grunde nichts falsch, aber ziemlich unübersichtlich. Das
> verkompliziert die Konfiguration nur und kann auch mal unerwartete
> Effekte haben, wenn die nicht übereinstimmen.
>
> > postconf -n
> > [..]
> > smtpd_delay_reject = yes
>
> bedeutet, dass alle Restrictions erst nach dem RCPT TO: abgearbeitet
> werden. Ist übrigens auch Standard. Die Einstellung kannst du eigentlich
> auch weg lassen.
>
> Dadurch ergeben sich zudem ein paar Vereinfachungen:
>
> > smtpd_helo_restrictions = permit_sasl_authenticated,
> > permit_mynetworks, reject_rbl_client multi.uribl.com,reject_rbl_client
> > dsn.rfc-ignorant.org,reject_rbl_client
> > dul.dnsbl.sorbs.net,reject_rbl_client list.dsbl.org,reject_rbl_client
> > sbl-xbl.spamhaus.org,reject_rbl_client
> > bl.spamcop.net,reject_rbl_client dnsbl.sorbs.net,reject_rbl_client
> > cbl.abuseat.org,reject_rbl_client
> > ix.dnsbl.manitu.net,reject_rbl_client
> > combined.rbl.msrbl.net,reject_rbl_client rabl.nuclearelephant.com,
> > reject_non_fqdn_sender, reject
>
> Abgesehen von reject_non_fqdn_sender sind deine helo_restrictions
> identisch zu den recipient_restrictions. Kannst du komplett streichen,
> den reject_non_fqdn_sender kann du bei den recipient_restrictions rein
> schreiben.
>
> > smtpd_recipient_restrictions = permit_sasl_authenticated,
> > permit_mynetworks, reject_rbl_client multi.uribl.com,reject_rbl_client
> > dsn.rfc-ignorant.org,reject_rbl_client
> > dul.dnsbl.sorbs.net,reject_rbl_client list.dsbl.org,reject_rbl_client
> > sbl-xbl.spamhaus.org,reject_rbl_client
> > bl.spamcop.net,reject_rbl_client dnsbl.sorbs.net,reject_rbl_client
> > cbl.abuseat.org,reject_rbl_client
> > ix.dnsbl.manitu.net,reject_rbl_client
> > combined.rbl.msrbl.net,reject_rbl_client rabl.nuclearelephant.com,
> > reject
>
> Hier muss alles rein, was nicht von deinen eigenen Usern kommt. Das
> permit_sasl_authenticated kannst du hier weglassen. Das
> permit_mynetworks prinzipiell auch; kannst du auch stehen lassen, macht
> keinen Unterschied.
>
> Warum? Es steht bereits hier vv.
>
> > smtpd_relay_restrictions = permit_mynetworks,
> > permit_sasl_authenticated, reject_unauth_destination,
>
> Die relay_restrictions werden unmittelbar vor den recipient restrictions
> abgearbeitet, sind aber ansonsten gleichwertig mit letzteren. Es sind
> die Restrictions für SASL.
>
> reject_unauth_destination macht hier keinen Sinn. Gehört eher in die
> recipient_restrictions ziemlich weit nach oben.
>
> Sinnvoll wäre (prinzipiell):
> sender-, helo-, client-restrictions leer lassen oder ganz streichen.
>
> dann:
> smtpd_relay_restrictions =
>   permit_mynetworks,
>   permit_sasl_authenticated
>
> smtpd_recipient_restrictions =
>   reject_unauth_destination
>   reject_non_fqdn_sender
>   reject_rbl_client multi.uribl.com
>   reject_rbl_client dul.dnsbl.sorbs.net
>   reject_rbl_client list.dsbl.org
>   reject_rbl_client sbl-xbl.spamhaus.org
>   reject_rbl_client bl.spamcop.net
>   reject_rbl_client dnsbl.sorbs.net
>   reject_rbl_client cbl.abuseat.org
>   reject_rbl_client ix.dnsbl.manitu.net
>   reject_rbl_client combined.rbl.msrbl.net
>   reject_rbl_client rabl.nuclearelephant.com
>   permit
>
> 2 Sachen hierzu:
> 1. Prüfe bitte, ob die RBL-Listen noch existieren. Mindestens
> rfc-ignorant.org gibts es nicht mehr. Die anderen habe ich mir jetzt
> nicht angesehen.
>
> 2. Ich habe hier was geändert, nämlich das abschließende reject durch
> ein permit ersetzt. Alles was die ganzen Restriktionen überlebt hat, ist
> geprüft und für dich bestimmt. Die Mails dürfen dann im allgemeinen auch
> rein. Das permit kann grundsätzlich auch einfach weg gelassen werden,
> man kann es der Übersicht halber auch stehen lassen.
>
> Wenn ich was vergessen haben sollte, schreibst du die fehlende
> Restriktion einfach in die recipient_restrictions. Die werden von oben
> nach unten abgearbeitet. Such dir die passende Stelle dafür aus, Bsp:
> unter dem "permit" wäre alles Blödsinn, es würde nie erreicht werden.
>

Danke schon mal für deine Hinweise.
Das mit den recipients habe ich gestern auch mit
reject_non_fqdn_sender gesetzt, was zur Folge hatte das von dem
privaten Mailaccount meiner Chefin an ihre dienstliche Mail alle paar
minuten eine Meldung vom Mail delivery System bekommen hat, wo drin
stand, das die recipient adresse rejected wurde aufgrund noch "need
fully-qualified adress". Der Grund ist mir auch klar:
vorname.nachname at domain.de wird nach uid at localhost ersetzt.
Also habe ich diesen Punkt wieder raus genommen und dann ging es mit
der Zustellung.

Ich werde das aber noch mal durchgehen und anpassen.

Gruß Sebastian

> --
> Kai Fürstenberg
>
> PM an: kai at fuerstenberg punkt ws
>


-- 
Mit freundlichen Grüßen
Sebastian Gödecke