AW: Verständnisfrage zu smtpd_tls_security_level / maincf und master.cf
postfix_dovecot at gmx.de
postfix_dovecot at gmx.de
Do Mai 23 13:10:01 CEST 2024
Hallo Markus,
1.000 Dank für diese wunderbare Erläuterung!!! Ich habe mich über die Arbeit, die Du dir gemacht hast sehr gefreut und bin jetzt wieder ein Stückchen schlauer!
Nochmals Danke und Gruß
Jens
-----Ursprüngliche Nachricht-----
Von: postfix-users <postfix-users-bounces+postfix_dovecot=gmx.de at de.postfix.org> Im Auftrag von Markus Winkler via postfix-users
Gesendet: Mittwoch, 22. Mai 2024 20:43
An: postfix-users at de.postfix.org
Betreff: Re: Verständnisfrage zu smtpd_tls_security_level / maincf und master.cf
Hallo Jens,
On 22.05.24 19:18, postfix_dovecot at gmx.de wrote:
> wenn ich "smtpd_tls_security_level=encrypt" auskommentiere (und damit "may" aus der main cf.angezogen wird) und "smtpd_tls_auth_only=no" setze, dann kann ich auch verschlüsselt oder unverschlüsselt Mail einliefern.
danke fürs Testen - schön, dass es funktioniert hat. ;-)
> Damit wäre die Problemstellung reproduzierbar und es ergibt sich für mich der Erkenntnisgewinn, dass sich die Parameter bedingen. Aber wo ist da der Sinn?
Stimmt, es gibt Abhängigkeiten. Genau genommen hängt aber eigentlich nur der smtpd_tls_auth_only von smtpd_tls_security_level ab - umgekehrt gibt es m. E. keine.
Eine Anmerkung vorweg: Man muss daran denken, dass wir ja hier nicht nur über Clients in Form von (klassischen Enduser-)MUAs (wie Outlook, Thunderbird, Claws Mail etc.) sprechen, sondern eben auch von alle anderen SMTP-Clients. Und dazu gehören z. B. andere Mailserver oder auch ein hornalter Scanner, die Mails einliefern möchten.
I.
Über smtpd_tls_security_level steuere ich als empfangender Server, welche Anforderungen ich hinsichtlich der Verschlüsselung der Transportschicht
(TLS) _generell(!)_ an meine Kommunikationspartner stelle:
(1) TLS wird gar nicht unterstützt (none)
(2) TLS wird angeboten, vom einliefernden Client (Server, MUA) aber nicht zwingend verlangt (may)
(3) TLS-Nutzung wird zwingend vorausgesetzt (encrypt)
Das ist also ein sehr entscheidender Aspekt, der über diesen Parameter gesteuert und beeinflusst wird.
II.
Eine "spezielle" Konstellation bei der Einlieferung von Mails ist die, dass vor Annahme der Mails durch den empfangenden Server eine Authentifizierung des einliefernden Clients gefordert wird. Dies wird hauptsächlich bei Szenarien von Bedeutung sein, in denen die oben erwähnten Enduser-Clients Mails versenden wollen und sich (heutzutage) natürlich am Mailserver authentifizieren müssen.
In dieser Situation kann ich als Server natürlich festlegen (smtpd_tls_security_level=encrypt), dass ich ausschließlich TLS-Verbindungen unterstütze (s. o.: (3)).
Damit wird die gesamte nachfolgende Kommunikation verschlüsselt ablaufen, inkl. der notwendigen Authentifizierung. Der Wert des Parameters smtpd_tls_auth_only ist in diesem Szenario daher quasi bedeutungslos. (Es schadet aber auch nicht, wenn er auf 'yes' gesetzt wird, denn mit STARTTLS kann man u. U. auch in Fallen tappen.)
Ist allerdings (2) definiert (smtpd_tls_security_level=may), dann lasse ich ja dem Client grundsätzlich einen gewissen Spielraum, was die Nutzung von TLS anbelangt: Ich als Server biete es an, erzwinge es aber nicht. Für diese Toleranz kann es Gründe geben. Ich kann aber in diesem Moment als Server gleichzeitig trotzdem verlangen, dass in den Fällen, die eine Authentifizierung erfordern, die Übertragung von sensiblen Anmeldedaten ausschließlich über TLS-gesicherte Verbindungen stattfindet:
smtpd_tls_auth_only=yes.
Daher haben m. E. beide Parameter ihre Berechtigung, wenngleich je länger je mehr smtpd_tls_auth_only an Bedeutung verlieren wird - idealerweise wird gerade auf den für Enduser-MUAs relevanten Submission- und SMTPS-Ports ausschließlich verschlüsselte Übertragung unterstützt, womit der Fall, dass Anmeldedaten ungesichert übertragen werden könnten, sowieso nicht mehr eintritt.
Sorry für den halben Roman und das weite Ausholen. Ich hoffe, das beantwortet Deine Fragen nach Sinn und Zusammenhang dieser Parameter ein wenig.
Viele Grüße
Markus
Mehr Informationen über die Mailingliste postfix-users