mcdaniels
Anmeldungsdatum: 15. September 2006
Beiträge: 119
Wohnort: Steiermark
|
Hallo community, ich habe hier ein Postfix in Version > 2.10 laufen. Die Authentifizierung geschieht mittels Dovecot / SASL. Submission auf Port 587 (STARTTLS) bzw. IMAPS auf Port 993. Ohne Authentifizierung ist kein Mailversand möglich. Ab dieser Version soll(t)en Restrictions, die das Postfix-Relaying betreffen, in die smtpd_relay_restrictions gepackt werden. Konkret geht es mir zwar um die main.cf (unten), jedoch poste ich der Vollständigkeit halber auch die master.cf 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 | smtp inet n - - - - smtpd
#smtp inet n - - - 1 postscreen
#smtpd pass - - - - - smtpd
#dnsblog unix - - - - 0 dnsblog
#tlsproxy unix - - - - 0 tlsproxy
submission inet n - - - - smtpd -v
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_enforce_tls=yes
-o smtpd_reject_unlisted_recipient=yes
-o smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
-o smtpd_sasl_tls_security_options=noanonymous
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
|
In der master.cf sind folgende restrictions aufgeführt:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22 | smtpd_recipient_restrictions = reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.easynet.nl,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
reject_unverified_recipient,
#Postgrey
check_policy_service inet:127.0.0.1:10023,
#Quota status
check_policy_service inet:127.0.0.1:12500,
permit
smtpd_relay_restrictions = reject_unauth_destination
|
reject_unauth_destination steht ausschließlich in den smtpd_relay_restrictions. Ist dies in dieser Form durchführbar bzw. in Ordnung / sicher? Danke!
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
mcdaniels schrieb: -o smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_destination,reject
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
Meines Erachtens ist reject_unauth_destination im Kontext von smtpd_client_restrictions wirkungslos und logisch falsch, zumal du vorher alle authentifizierten User zulässt, und danach alles rejectest. Rein technisch würde es hier in die eine Zeile darunter befindliche Option smtpd_relay_restrictions gehören. Das ist aber auch wieder sinnlos, da reject_unauth_destination im Senden-Kontext generell keinen Sinn macht. Denn es bedeutet ja, dass keine Mails an unbekannte Ziele gesendet werden dürfen. Das muss du immer mit permit_sasl_authenticated aushebeln. Im Senden-Kontext (also Submission) kannst du dir, wenn du noch etwas mehr Kontrolle haben willst, smtpd_sender_login_maps und reject_sender_login_mismatch angucken. Wenn das nicht gesetzt ist, kann prinzipiell jeder authentifizierte User mit jeder Email-Adresse senden, die Postfix plausibel erscheint – auch welche, die er selbst gar nicht verwaltet.
In der master.cf sind folgende restrictions aufgeführt:
smtpd_relay_restrictions = reject_unauth_destination
reject_unauth_destination steht ausschließlich in den smtpd_relay_restrictions.
Hier macht das wiederum Sinn.
Ist dies in dieser Form durchführbar bzw. in Ordnung / sicher?
Ja. Zumindest ist dein Postfix damit kein offenes Relay. Im Zweifelsfall lässt sich das auch mit diesem Tool testen.
|
mcdaniels
(Themenstarter)
Anmeldungsdatum: 15. September 2006
Beiträge: 119
Wohnort: Steiermark
|
Hallo,
danke für die Infos! Ich habe ja die smtpd_relay_restrictions in meiner main.cf nach den smtpd_recipient_restrictions stehen. die smtpd_recipient_restrictions enden mit einem "permit". Danach kommen die smtpd_relay_restrictions. Im Log hab ich gerade folgendes gesehen:
postfix/smtpd[1519]: warning: restriction `smtpd_relay_restrictions' after `permit' is ignored Weshalb ich die Konfiguration nun wie folgend umgebaut habe (permit von den recipient_restrictions_entfernt und am Ende zu den relay_restrictions hinzugefügt): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 | smtpd_recipient_restrictions = reject_rbl_client sbl.spamhaus.org,
reject_rbl_client blackholes.easynet.nl,
permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_hostname,
reject_invalid_hostname,
reject_non_fqdn_recipient,
reject_non_fqdn_sender,
reject_unknown_recipient_domain,
reject_unauth_pipelining,
reject_unverified_recipient,
#Postgrey
check_policy_service inet:127.0.0.1:10023,
#Quota status
check_policy_service inet:127.0.0.1:12500,
smtpd_relay_restrictions = reject_unauth_destination,
permit
|
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
mcdaniels schrieb: Ich habe ja die smtpd_relay_restrictions in meiner main.cf nach den smtpd_recipient_restrictions stehen.
In welcher Reihenfolge die Direktiven in der Konfiguration auftauchen ist irrelevant. Die Auswertung dieser erfolgt an definierten Stellen beim Anliefern der Mail. Siehe dazu die Tabelle in diesem Abschnitt.
die smtpd_recipient_restrictions enden mit einem "permit".
Warum? Meines Erachtens braucht man in einer sauberen Postfix-Konfiguration gar kein einzelnes "permit", denn das ist ein absolutes "JA DU DARFST". Alle nachstehenden Checks werden ignoriert.
Im Log hab ich gerade folgendes gesehen:
postfix/smtpd[1519]: warning: restriction `smtpd_relay_restrictions' after `permit' is ignored
Diese Fehlermeldung scheint daraus zu resultieren, dass nach dem permit in smtpd_recipient_restrictions die smtpd_relay_restrictions gar nicht mehr ausgewertet werden. Das willst du nicht.
Weshalb ich die Konfiguration nun wie folgend umgebaut habe (permit von den recipient_restrictions_entfernt und am Ende zu den relay_restrictions hinzugefügt):
| smtpd_relay_restrictions = reject_unauth_destination,
permit
|
Wie gesagt, das permit würde ich einfach weglassen, damit du keinen nachgelagerten Check aushebelst. Gibt es keinen nachgelagerten Check, ist permit sowieso die Standard-Aktion.
|
mcdaniels
(Themenstarter)
Anmeldungsdatum: 15. September 2006
Beiträge: 119
Wohnort: Steiermark
|
Hallo, In welcher Reihenfolge die Direktiven in der Konfiguration auftauchen ist irrelevant.
Postfix wertet also die Restrictions nach dem Mail-Kommunikationsstatus aus. Reihenfolge egal. Denke aber trotzdem, dass es besser ist die Restrictions in der Reihenfolge in der Konfig stehen zu haben, wie auch die Kommunikation stattfindet.Nicht vom technischen Standpunkt her, sondern eher von der Lesbarkeit. Ich denke, es gehen ja nicht alle so vor, dass sie die client, helo und sender_restrictions in die recipient_restrictions packen. Die Doku von Postfix selbst, rät eigentlich eher davon ab, "alles" zusammenzupacken. (http://www.postfix.org/SMTPD_ACCESS_README.html) – Dangerous use of smtpd_recipient_restrictions Peer Heinlein sagt jedoch "Konsequenz der Abarbeitung der Restrictions ist, dass man alles in die smtpd_recipient_restrictions packt und die andren Restrictions leer lässt, da ja ohnehin immer bis dorthin alles abgearbeitet wird." Übersichtlicher wird wohl die Aufteilung sein.
Diese Fehlermeldung scheint daraus zu resultieren, dass nach dem permit in smtpd_recipient_restrictions die smtpd_relay_restrictions gar nicht mehr ausgewertet werden. Das willst du nicht.
Korrekt, deshalb hab ich es umgebaut.
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
mcdaniels schrieb: Nicht vom technischen Standpunkt her, sondern eher von der Lesbarkeit. Ich denke, es gehen ja nicht alle so vor, dass sie die client, helo und sender_restrictions in die recipient_restrictions packen.
Sicherlich, die Bemerkung zur Reihenfolge war nur ein Hinweis 😉
Die Doku von Postfix selbst, rät eigentlich eher davon ab, "alles" zusammenzupacken.
Das ist richtig. In neueren Postfix-Versionen wurden die Restriction-Direktiven aufgesplittet, um fehlerhafte Setups zu vermeiden. Nichtsdestotrotz ist diese logische Aufteilung aber nur für die Übersichtlichkeit da. Es hat sich nichts daran geändert, an welcher Stelle die Direktiven ausgewertet werden. Es ist also nach wie vor möglich, auch ein korrektes Setup ausschließlich mit smtpd_recipient_restrictions zu bauen. Das wichtigste an so einem Setup ist also, dass man verstanden hat, wie die Auswertung der Restrictions stattfindet, und dass die Reihenfolge der Checks innerhalb der Direktiven ausschlaggebend ist. Das Beispiel in dem von dir erwähnten Abschnitt macht das nochmal deutlich.
Peer Heinlein sagt jedoch "Konsequenz der Abarbeitung der Restrictions ist, dass man alles in die smtpd_recipient_restrictions packt und die andren Restrictions leer lässt, da ja ohnehin immer bis dorthin alles abgearbeitet wird."
Das ist seine Meinung. Den von dir angeführten Abschnitt der Postfix-Doku könnte man daher als Replik zu dieser Meinung werten.
Übersichtlicher wird wohl die Aufteilung sein.
Das sehe ich auch so.
|
mcdaniels
(Themenstarter)
Anmeldungsdatum: 15. September 2006
Beiträge: 119
Wohnort: Steiermark
|
Hi,
eine Frage noch. Es gibt viele Konfigurationen wie untenstehend (nur ein Auszug).
(permit) denn das ist ein absolutes "JA DU DARFST". Alle nachstehenden Checks werden ignoriert.
1
2
3
4
5
6
7
8
9
10
11
12
13
14 | smtpd_helo_restrictions = permit_mynetworks,
reject_non_fqdn_hostname,
reject_invalid_hostname,
''' permit'''
smtpd_sender_restrictions = permit_mynetworks,
permit_sasl_authenticated,
reject_non_fqdn_sender,
reject_unknown_sender_domain,
''' permit'''
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated,
|
Bezogen auf obige Konfig:
Wenn von den helo_restrictions ein Reject retour kommt, wird die Kommunikation nach dem RCPT TO beendet. Sofern sich der Client in mynetworks befindet, ergibt sich ein PERMIT. Prüfung in der Restriction wird beendet. Es wird zur nächsten Restriction gesprungen. Wenn jedoch weder ein Permit noch ein Reject ausgelöst wird, dann hätten wir für jede Regel ein Dunno. Somit werden die smtpd_helo_restrictions Regel für Regel abgearbeitet und man landet zwangsläufig beim permit. Das permit in den helo_restrictions führt aber nicht dazu, dass die sender_restrictions usw. nicht mehr abgearbeitet werden. Deshalb versteh ich nicht ganz, warum bei meiner Ausgangskonfiguration, die Warnung "warning: restriction smtpd_relay_restrictions' after permit' is ignored" kam. Danke nochmals!
|
misterunknown
Ehemalige
Anmeldungsdatum: 28. Oktober 2009
Beiträge: 4403
Wohnort: Sachsen
|
mcdaniels schrieb: Wenn jedoch weder ein Permit noch ein Reject ausgelöst wird, dann hätten wir für jede Regel ein Dunno.
Nein, das Ende einer Direktive ist gleichzusetzen mit einem permit. Ignoriert werden nur eventuelle nachstehende Regeln innerhalb der selben Direktive (siehe, im Absatz nach der Konfiguration). Meine Empfehlung am Ende einer Direktive kein permit zu setzen hat eher den Hintergrund, dass man nicht versehentlich danach noch einen Check einbaut, der dann nicht wirkt.
Das permit in den helo_restrictions führt aber nicht dazu, dass die sender_restrictions usw. nicht mehr abgearbeitet werden.
Richtig.
Deshalb versteh ich nicht ganz, warum bei meiner Ausgangskonfiguration, die Warnung "warning: restriction smtpd_relay_restrictions' after permit' is ignored" kam.
Kann es sein, dass du nach dem permit noch ein Komma hattest, und er daher smtpd_relay_restrictions noch als Check angesehen hat? Ich kann die Fehlermeldung von dir bei mir nicht nachstellen.
|
mcdaniels
(Themenstarter)
Anmeldungsdatum: 15. September 2006
Beiträge: 119
Wohnort: Steiermark
|
Nein, das Ende einer Direktive ist gleichzusetzen mit einem permit.
Ok, das war mir nicht bewusst. (Im Nachhinein betrachtet, aber logisch) - Danke!
Kann es sein, dass du nach dem permit noch ein Komma hattest, und er daher smtpd_relay_restrictions noch als Check angesehen hat? Ich kann die Fehlermeldung von dir bei mir nicht nachstellen.
Das hab ich mir auch grade vorhin gedacht, weil eben das permit nur innerhalb der Restriction wirkt und die smtpd_relay_restrictions ja gar nicht innerhals der recipient_restrictions "liegt". Ich glaub mir ist da in der Tat gestern ein Komma "kleben" geblieben, das ich dann im Zuge des Umbaues (unbewusst) entfernt habe. Kann es selbst nicht mehr reproduzieren. So ein Schmarren! Jedenfalls herzlichen Dank für deine Unterstützung. (Ich bin jetzt um einiges weiser) ☺
|