* Walter H. Walter.H@mathemainzel.info:
On 28.12.2017 22:11, Patrick Ben Koetter wrote:
- Frank Röhmfrancwalter@gmx.net:
Im Moment muss ich ja "Passwort, normal" auswählen, damit es geht. Das ist ja auch nicht optimal.
Es ist optimal, auch wenn es auf den ersten Blick nicht so wirkt, *solange* Du STARTTLS vor dem AUTH erzwingst.
Wenn Du eine TLS-verschlüsselte Verbindung erzwingst (nur auf Port 587) sind
nicht ganz; Port 587 ist der Submissionport, welcher wenn der Serveradmin es komplett verkorkst gar keine Verschlüsselung geben muss; Port 465 ist der SMTPS-Port (das SMTP-pendant) zu HTTPS mit Port 443 ...
Ich präzisiere: Das darfst Du nur auf 587 erzwingen, denn auf dem Port 25 können auch MTAs aufschlagen, die gar kein TLS können und die könnten in dem Fall nicht einmal einen Mail an postmaster@DOMAIN absetzen, um ihr Problem zu schildern.
Du kannst auch den 465er nehmen, da wird halt gar nicht verhandelt, ob der Client SSL/TLS sprechen möchte, sondern gleich damit begonnen.
wobei ich habe auch schon reines unverschlüsseltes HTTP auf Port 443 erlebt ...
In so einem Umfeld ist es sicher (so sicher wie TLS ist), wenn Du Benutzername und Kennwort per PLAIN/LOGIN (lies: "Passwort, normal") an den Server senden lässt.
Thunderbird, ändert hier die Anzeige, wenn man von 'None' auf 'STARTTLS' od. 'SSL/TLS' umstellt; bei 'None' wird an Stelle von 'Normal password' dann 'Password, transmitted insecurely' angezeigt; ich kenne kaum ein System, welches tatsächlich ohne SSL eine fehlerfreie verschlüsselte Übertragung von UserId / Passwort ermöglicht ...
OT: Da wird, wie leider meist bei Sicherheit, viel Nebel erzeugt, damit das ja keiner auf das erste Mal versteht und womöglich sogar einfach und anwendbar findet. Diese Kompliziertheit dient dann höchstens den Entwicklern, die sich toll finden dürfen, weil sie etwas so schwieriges meistern konnten: "Dafür muss man sich auskennen! Sonst bist Du nicht würdig!"
Schwierig ist leicht was. Es leicht zu machen, ist schwierig. Dieser Herausforderung stellen sich die wenigsten in der IT. Ein Programm hat viele Interfaces, die gestaltet werden müssen:
- Betriebsystem An der Stelle arbeiten die Entwickler die meiste Zeit - Andere Programme Daran arbeiten sie ebenfalls, weil es ja kompatibel (mit Standards) sein muss - Administrator/Anwender Daran arbeiten sie eher selten. Wietse hat intensivst für Postfix daran gearbeitet. Wie wenig Arbeit in amavis oder rspamd geflossen ist, erlebt man sofort wenn man sich den Programmen nähert. Das Interface von Thunderbird stammt aus den 90ern - leider. Aber da Geld auszugeben lohnt nicht mehr. Die Tage der Desktop-Clients sind gezählt.
Der Server, bzw. der sog. Password Verification Service (hier: Dovecot), nimmt die Daten entgegen, prüft im Backend, ob das übergebene Passwort mit dem User, der gesendet wurde, mit dem gecrypteten Passwort "passt".
hier gibt es 2 Arten, entweder es handelt sich um echte User am Linux-System
- so habe ich es gemacht,
oder aber eine eigene vom System losgelöste Verwaltung von Usern (die UserIds sind hier dann Mailadressen);
den Unterschied kennt man, ob der User in der /etc/passwd zu finden ist oder in der sasldb ...
Es gibt noch viel mehr authentication backends auf die ein password verification service zugreifen kann. Wenn Du dovecot als PWS verwendest, sind das alle auth-Dienste, die dovecot ansprechen kann. Im Fall von Cyrus SASL kannst Du unter pwcheck_method eine Liste von methods angeben, welche die libsasl dann auf der Suche nach Authentifizierung abklappert. Mehr dazu habe ich hier beschrieben:
https://sys4.de/de/blog/2015/01/07/cyrus-sasl-libsasl-man-page/
p@rick