* Stefanie Leisestreichler stefanie.leisestreichler@peter-speer.de:
Am 20.02.19 um 14:46 schrieb Patrick Ben Koetter:
Kann es sein, dass Du AUTH nur dann gestattest, wenn eine TLS-Session existiert? Das ist dann der Fall, wenn Du entweder smtpd_tls_auth_only gesetzt hast oder smtpd_tls_security_level=encrypt forderst.
Das war der entscheidende Hinweis: smtpd_tls_auth_only war gesetzt. Nach dem Setzen auf "no" kommt 250-AUTH PLAIN LOGIN und 250-AUTH=PLAIN LOGIN nach der erfolgreich ausgehandelten TLS-Session.
Ich habe jetzt meine Konfiguration jetzt in diesem Bereich so abgeändert, dass sie Deiner entspricht:
smtpd_tls_security_level=encrypt smtpd_tls_auth_only = no
Du kannst das "smtpd_tls_auth_only = no" in der config weglassen, denn das Verhalten ist default.
Eine Frage stellt sich mir hierbei: Das heisst doch implizit, dass niemand dort Mails einkippen kann, der nicht in der Lage ist eine TLS-Session aufzubauen, oder irre ich mich?
Wenn Du smtpd_tls_security_level=encrypt setzt, dann erzwingt der Postfix smtpd Server eine TLS-Session. Ohne TLS wird er nicht mit dem Client sprechen.
Weil die RFCs verbieten auf einem "publicly referenced MTA" (lies: MTA, welcher laut DNS der MX ist) TLS zu erzwingen, darf man seinen MX deshalb auf Port 25 nicht mit smtpd_tls_security_level=encrypt betreiben.
Für MUAs (lies: Outlook, Thunderbird etc.) richten Postmaster und -mistresses deshalb zusätzlich eine smtpd-Instanz auf Port 587 ein. Dort erzwingen wir TLS und *nur dort* bieten wir auch AUTH an. Und auch *nur dann* wenn eine TLS-Session etabliert wurde.
Der Grund hierfür ist: Nur die SASL Mechanismen PLAIN und LOGIN gestatten eine kryptierte Speicherung von Passworten, die es bei Diebstahl schwierig bis unmöglich machen, sie zu nutzen. Wer PLAIN und LOGIN einsetzt, holt sich damit aber den Nachteil an Bord, dass diese SASL-Mechanismen als base64 kodierter Plaintext (lies: ungeschützt) über den Ether gehen.
Um ein Abfangen der Identität (Login, Kennwort) bei der Übertragung zu verhindern, erzwingen wir deshalb TLS. Dann ist die Strecke zwischen MUA und MSA – so heißt ein MTA, der Submission auf Port 587 anbietet – verschlüsselt und PLAIN oder LOGIN können sicher genutzt werden.
Und: Wie wirkt sich das bspw. auf Scripts aus, die z.B. per "mail" aus $mynetworks getriggert werden. Können diese dann überhaupt noch dort abgeladen werden?
Diese Frage verstehe ich nicht ganz. Meinst Du damit Skripte, die aus Netzwerksicht aus $mynetworks kommend eine Mail bei Deinem Postfix Server abgeben wollen? Wenn sie (client) in $mynetworks sind und der Server eine Regel permit_mynetworks in einer der smtpd_*_restrictions hat, dann sollten die Skripte an interne Ziele senden und sogar an externe Ziele relayen dürfen. Eine AUTH ist dafür nicht erforderlich, weil sie durch permit_mynetworks autorisiert werden.
Herzlichen Dank an alle für die nette Hilfe.
Gerne.
HTH
p@rick