restrictions einbauen

[Kai Fürstenberg]

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.

-- 
Kai Fürstenberg

PM an: kai at fuerstenberg punkt ws