Dovecot Sasl | Auth not enabled

[Patrick Ben Koetter]

* Stefanie Leisestreichler <stefanie.leisestreichler at 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 at rick

-- 
[*] sys4 AG
 
https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein