Authentifizierung in Thunderbird "Verschlüsseltes Passwort"
Hallo
was muss ich denn in meinem Postfix anbieten, damit ich beim Erstellen eines Kontos in Thunderbird unter Authentifizierung "Verschlüsseltes Passwort" verwenden kann? Dovecot macht die Authentifizierung meines Postfix nach der Anleitung: https://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
Ich habe derzeit Postfix Version 2.11.0-1ubuntu1.2 und Dovecot in Version: 2.2.9-1ubuntu2.1 auf Ubuntu 14.04 LTS
postconf -a ergibt:
cyrus dovecot
postconf -n ergibt:
alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases,hash:/var/lib/mailman/data/aliases append_dot_mydomain = no bounce_template_file = /etc/postfix/bounce.de-DE.cf broken_sasl_auth_clients = yes config_directory = /etc/postfix content_filter = smtp-amavis:[127.0.0.1]:10024 default_process_limit = 500 dovecot_destination_recipient_limit = 1 greylist = check_policy_service inet:127.0.0.1:60000 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 message_size_limit = 51200000 milter_default_action = accept milter_protocol = 2 mydestination = localhost, lists.example.org myhostname = example.org myorigin = /etc/mailname non_smtpd_milters = inet:localhost:12301 queue_directory = /var/spool/postfix readme_directory = no receive_override_options = no_address_mappings recipient_delimiter = + smtp_tls_loglevel = 1 smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) smtpd_data_restrictions = reject_unauth_pipelining smtpd_discard_ehlo_keywords = dsn smtpd_hard_error_limit = 100 smtpd_milters = inet:localhost:12301 smtpd_recipient_restrictions = reject_unknown_sender_domain, reject_unknown_recipient_domain, permit_mynetworks, reject_unlisted_recipient, reject_non_fqdn_sender, reject_non_fqdn_recipient, reject_unlisted_sender, permit_sasl_authenticated, reject_unauth_destination, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_client_hostname, reject_unknown_helo_hostname, check_recipient_access hash:/etc/postfix/roleaccount_exceptions, check_client_access hash:/etc/postfix/rbl_client_exceptions, check_policy_service inet:127.0.0.1:10040, reject_rbl_client zen.spamhaus.org smtpd_restriction_classes = greylist smtpd_sasl_auth_enable = yes smtpd_sasl_authenticated_header = yes smtpd_sasl_path = private/auth smtpd_sasl_type = dovecot smtpd_soft_error_limit = 80 smtpd_tls_auth_only = no smtpd_tls_cert_file = /etc/apache2/ssl/servercert.pem smtpd_tls_dh1024_param_file = /etc/postfix/dh_1024.pem smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem smtpd_tls_eecdh_grade = strong smtpd_tls_key_file = /etc/apache2/ssl/serverkey.pem smtpd_tls_loglevel = 1 smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_use_tls = yes soft_bounce = no tls_preempt_cipherlist = yes unknown_local_recipient_reject_code = 550 virtual_alias_maps = mysql:/etc/postfix/mysql-virtual-alias-maps.cf,mysql:/etc/postfix/mysql-email2email.cf virtual_gid_maps = static:5000 virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual-mailbox-domains.cf virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual-mailbox-maps.cf virtual_transport = dovecot virtual_uid_maps = static:5000
Danke für einen kleinen Tipp
franc
* Frank Walter francwalter@gmx.net:
Hallo
was muss ich denn in meinem Postfix anbieten, damit ich beim Erstellen eines Kontos in Thunderbird unter Authentifizierung "Verschlüsseltes Passwort" verwenden kann? Dovecot macht die Authentifizierung meines Postfix nach der Anleitung: https://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
"Verschlüsseltes Passwort" bedeutet: Das Passwort wird verschlüsselt übertragen, aber es muss unverschlüsselt (plaintext) im Backend (passwdfile, SQL, LDAP...) abgelegt sein.
Bist Du Dir sicher, dass Du das willst?
Sicherer wäre:
- Erzwinge STARTTLS in der Session (SMTP/IMAP) - Gestatte (in der dann geschützten Umgebung) PLAIN/LOGIN als SASL Methoden
Das Passwort kannst Du dann auf dem Server crypten wie Du willst.
Auf diese Weise ist das Kennwort während des Transports und im Backend geschützt.
p@rick
Am 28.12.2017 um 16:34 schrieb Patrick Ben Koetter p@sys4.de:
- Frank Walter francwalter@gmx.net:
Hallo
was muss ich denn in meinem Postfix anbieten, damit ich beim Erstellen eines Kontos in Thunderbird unter Authentifizierung "Verschlüsseltes Passwort" verwenden kann? Dovecot macht die Authentifizierung meines Postfix nach der Anleitung: https://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
"Verschlüsseltes Passwort" bedeutet: Das Passwort wird verschlüsselt übertragen, aber es muss unverschlüsselt (plaintext) im Backend (passwdfile, SQL, LDAP...) abgelegt sein.
Bist Du Dir sicher, dass Du das willst?
Im Moment muss ich ja "Passwort, normal" auswählen, damit es geht. Das ist ja auch nicht optimal.
Sicherer wäre:
- Erzwinge STARTTLS in der Session (SMTP/IMAP)
STARTTLS wähle ich auch immer aus.
- Gestatte (in der dann geschützten Umgebung) PLAIN/LOGIN als SASL Methoden
Das Passwort kannst Du dann auf dem Server crypten wie Du willst.
Auf dem Server ist in der Datenbank das Passwort als MD5 abgelegt.
Mein Problem ist mit Delta Chat (der sichere Chat Client der über Mail läuft, siehe: delta.chat), dort kann sich Delta Chat (an einem Konto meines Mailservers) nicht anmelden. Ein Auszug aus dem Log:
Nov 27 12:21:10 ew6 postfix/smtpd[19421]: connect from x4db0daba.dyn.telefonica.de[77.176.218.186] Nov 27 12:21:10 ew6 postfix/smtpd[19421]: Anonymous TLS connection established from x4db0daba.dyn.telefonica.de[77.176.218.186]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Nov 27 12:21:10 ew6 postfix/smtpd[19421]: discarding EHLO keywords: DSN Nov 27 12:21:12 ew6 postfix/smtpd[19421]: warning: x4db0daba.dyn.telefonica.de[77.176.218.186]: SASL DIGEST-MD5 authentication failed: cmVhbG09IiIsbm9uY2U9IkE4MVRYaHk5L0ZjUEhoWXhranQxNFE9PSIscW9wPSJhdXRoIixjaGFyc2V0PSJ1dGYtOCIsYWxnb3JpdGhtPSJtZDUtc2VzcyI= Nov 27 12:21:12 ew6 postfix/smtpd[19421]: disconnect from x4db0daba.dyn.telefonica.de[77.176.218.186]
DIGEST-MD5 funktioniert also nicht, ich habe das als das Pendant bei Thunderbird "Passwort, verschlüsselt" verstanden. Vielleicht täusche ich mich?
* Frank Röhm francwalter@gmx.net:
Am 28.12.2017 um 16:34 schrieb Patrick Ben Koetter p@sys4.de:
- Frank Walter francwalter@gmx.net:
Hallo
was muss ich denn in meinem Postfix anbieten, damit ich beim Erstellen eines Kontos in Thunderbird unter Authentifizierung "Verschlüsseltes Passwort" verwenden kann? Dovecot macht die Authentifizierung meines Postfix nach der Anleitung: https://wiki2.dovecot.org/HowTo/PostfixAndDovecotSASL
"Verschlüsseltes Passwort" bedeutet: Das Passwort wird verschlüsselt übertragen, aber es muss unverschlüsselt (plaintext) im Backend (passwdfile, SQL, LDAP...) abgelegt sein.
Bist Du Dir sicher, dass Du das willst?
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 alle Daten, die zwischen Client und Server ausgetauscht werden, geschützt. Sie sind nur zwischen Client und Server "sichtbar".
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.
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".
Ist das der Fall, teilt der Password Verification Service (Dovecot) Postfix den Erfolg ("Authentication sucessful") mit. Das ist der Auslöser für Postfix, den Client zu autorisieren, dass er die E-Mail senden (relayen) darf.
Sicherer wäre:
- Erzwinge STARTTLS in der Session (SMTP/IMAP)
STARTTLS wähle ich auch immer aus.
- Gestatte (in der dann geschützten Umgebung) PLAIN/LOGIN als SASL Methoden
Das Passwort kannst Du dann auf dem Server crypten wie Du willst.
Auf dem Server ist in der Datenbank das Passwort als MD5 abgelegt.
Mein Problem ist mit Delta Chat (der sichere Chat Client der über Mail läuft, siehe: delta.chat), dort kann sich Delta Chat (an einem Konto meines Mailservers) nicht anmelden. Ein Auszug aus dem Log:
Nov 27 12:21:10 ew6 postfix/smtpd[19421]: connect from x4db0daba.dyn.telefonica.de[77.176.218.186] Nov 27 12:21:10 ew6 postfix/smtpd[19421]: Anonymous TLS connection established from x4db0daba.dyn.telefonica.de[77.176.218.186]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) Nov 27 12:21:10 ew6 postfix/smtpd[19421]: discarding EHLO keywords: DSN Nov 27 12:21:12 ew6 postfix/smtpd[19421]: warning: x4db0daba.dyn.telefonica.de[77.176.218.186]: SASL DIGEST-MD5 authentication failed: cmVhbG09IiIsbm9uY2U9IkE4MVRYaHk5L0ZjUEhoWXhranQxNFE9PSIscW9wPSJhdXRoIixjaGFyc2V0PSJ1dGYtOCIsYWxnb3JpdGhtPSJtZDUtc2VzcyI= Nov 27 12:21:12 ew6 postfix/smtpd[19421]: disconnect from x4db0daba.dyn.telefonica.de[77.176.218.186]
DIGEST-MD5 funktioniert also nicht, ich habe das als das Pendant bei Thunderbird "Passwort, verschlüsselt" verstanden. Vielleicht täusche ich mich?
DIGEST-MD5 kann prinzipbedingt nicht funktionieren, wenn Du das Kennwort als MD5 abgelegt hast. DIGEST-MD5 gehört zu den Shared-Secret-Mechanismen und die benötigen zwingend, dass das Kennwort unverschlüsselt abgelegt wird.
Kannst Du mir mal folgendes zeigen:
Mach ein "telnet $DEINSERVER 25" und sende den Output von nach dem "EHLO x4db0daba.dyn.telefonica.de" hier auf die Liste. Dann wissen wir, ob Dein Server DIGEST-MD5 anbietet. Das sollte er nämlich nicht, wenn er keine Shared-Secred-Mechanismen verarbeiten kann.
p@rick
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 ...
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 ...
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 ...
* 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
On 29.12.2017 08:50, Patrick Ben Koetter wrote:
- 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.
für die eigene Domain vielleicht gar nicht mal so doof, auf die Art zu sagen: "besorg Dir einen ordentlichen Mailserver, wennst mir SPAM schicken willst"
- 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.
mein Mailserver kommt mit Postfix/OpenDKIM/OpenDMARC aus, keine Notwendigkeit f. SPAMassassin, amavis, ...
Das Interface von Thunderbird stammt aus den 90ern - leider.
als ob der Pfusch der "Gegenwart" was Interfaces betriffft, da besser ist;
Aber da Geld auszugeben lohnt nicht mehr. Die Tage der Desktop-Clients sind gezählt.
ob die Welt der "Heizflossen" besser ist, wage ich mal zu bezweifeln;
Am 29.12.2017 um 16:31 schrieb Walter H.:
On 29.12.2017 08:50, Patrick Ben Koetter wrote:
- 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.
für die eigene Domain vielleicht gar nicht mal so doof, auf die Art zu sagen: "besorg Dir einen ordentlichen Mailserver, wennst mir SPAM schicken willst"
- 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.
mein Mailserver kommt mit Postfix/OpenDKIM/OpenDMARC aus, keine Notwendigkeit f. SPAMassassin, amavis, ...
schoen fuer dich, das kann sich aber zu jeder Zeit aendern ein weit verbreitetes Problem von sich auf andere zu schliessen, wenn man mal ein paar hundert/tausend Mailboxen hostet wird das unverzichtbar, ich kennen sogar domains mit nur einer Handvoll Mailadressen, die so zugespammed werden dass man nur dafuer schon high performance Mailserver und filter braucht.
Das Interface von Thunderbird stammt aus den 90ern - leider.
als ob der Pfusch der "Gegenwart" was Interfaces betriffft, da besser ist;
Aber da Geld auszugeben lohnt nicht mehr. Die Tage der Desktop-Clients sind gezählt.
ob die Welt der "Heizflossen" besser ist, wage ich mal zu bezweifeln;
ein grosser Mail Hoster wird dir aber "premium" support nur fuer "seinen" Mail Client anbieten, das ist fuer gewoehnlich ein webmail, fuer den Rest kannst du froh sein wenn es Faqs gibt und/oder du bezahlst "extra" dafuer.
Wie Patrick gesagt hat der Kern des Problems bei den Clients ist die langfristige Finanzierung, Versuche in der Vergangenheit dass ueber den Software Verkauf zu finanzieren sind gescheitert. Als wirklicher Multi OS Mailclient hat nur Thunderbird ueberlebt, dessen weitere Faehigkeiten mit Kalendern und Adressbuechern ist aber nicht auf der Hoehe der Zeit.
Best Regards MfG Robert Schetterer
Am 28.12.2017 um 22:11 schrieb Patrick Ben Koetter p@sys4.de:
DIGEST-MD5 kann prinzipbedingt nicht funktionieren, wenn Du das Kennwort als MD5 abgelegt hast. DIGEST-MD5 gehört zu den Shared-Secret-Mechanismen und die benötigen zwingend, dass das Kennwort unverschlüsselt abgelegt wird.
Kannst Du mir mal folgendes zeigen:
Mach ein "telnet $DEINSERVER 25" und sende den Output von nach dem "EHLO x4db0daba.dyn.telefonica.de" hier auf die Liste. Dann wissen wir, ob Dein Server DIGEST-MD5 anbietet. Das sollte er nämlich nicht, wenn er keine Shared-Secred-Mechanismen verarbeiten kann.
EHLO x4db0daba.dyn.telefonica.de 250-ew6.org 250-PIPELINING 250-SIZE 51200000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-AUTH=PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-ENHANCEDSTATUSCODES 250 8BITMIME
warum bietet mein Postfix da bloß DIGEST-MD5 an, wenn er es nicht kann? Fehlkonfiguriert? Wo schalte ich das ab?
Danke
Am 03.01.2018 um 12:34 schrieb Frank Röhm francwalter@gmx.net:
Am 28.12.2017 um 22:11 schrieb Patrick Ben Koetter p@sys4.de:
DIGEST-MD5 kann prinzipbedingt nicht funktionieren, wenn Du das Kennwort als MD5 abgelegt hast. DIGEST-MD5 gehört zu den Shared-Secret-Mechanismen und die benötigen zwingend, dass das Kennwort unverschlüsselt abgelegt wird.
Kannst Du mir mal folgendes zeigen:
Mach ein "telnet $DEINSERVER 25" und sende den Output von nach dem "EHLO x4db0daba.dyn.telefonica.de" hier auf die Liste. Dann wissen wir, ob Dein Server DIGEST-MD5 anbietet. Das sollte er nämlich nicht, wenn er keine Shared-Secred-Mechanismen verarbeiten kann.
EHLO x4db0daba.dyn.telefonica.de 250-ew6.org 250-PIPELINING 250-SIZE 51200000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-AUTH=PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-ENHANCEDSTATUSCODES 250 8BITMIME
warum bietet mein Postfix da bloß DIGEST-MD5 an, wenn er es nicht kann? Fehlkonfiguriert? Wo schalte ich das ab?
Selbst gefunden: in der /etc/dovecot/conf.d/10-auth.conf war doch tatsächlich gestanden:
auth_mechanisms = plain digest-md5 cram-md5 a pop login
das habe ich mal schnell geändert zu:
auth_mechanisms = plain pop login
und jetzt geht die Verbindung mit Delta Chat, weil weder digest-md5 noch cram-md5 mehr probiert wird (was ja gar nicht geht).
Danke!
* Frank Röhm francwalter@gmx.net:
Am 28.12.2017 um 22:11 schrieb Patrick Ben Koetter p@sys4.de:
DIGEST-MD5 kann prinzipbedingt nicht funktionieren, wenn Du das Kennwort als MD5 abgelegt hast. DIGEST-MD5 gehört zu den Shared-Secret-Mechanismen und die benötigen zwingend, dass das Kennwort unverschlüsselt abgelegt wird.
Kannst Du mir mal folgendes zeigen:
Mach ein "telnet $DEINSERVER 25" und sende den Output von nach dem "EHLO x4db0daba.dyn.telefonica.de" hier auf die Liste. Dann wissen wir, ob Dein Server DIGEST-MD5 anbietet. Das sollte er nämlich nicht, wenn er keine Shared-Secred-Mechanismen verarbeiten kann.
EHLO x4db0daba.dyn.telefonica.de 250-ew6.org 250-PIPELINING 250-SIZE 51200000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-AUTH=PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-ENHANCEDSTATUSCODES 250 8BITMIME
warum bietet mein Postfix da bloß DIGEST-MD5 an, wenn er es nicht kann? Fehlkonfiguriert? Wo schalte ich das ab?
Du nutzt dovecot als PWS, ja? Prüfe mal:
doveconf auth_mechanisms
Wenn da mehr als plain und login im Output steht, dann solltest Du auth_mechanisms anpassen - entweder in der 10-auth.conf oder in der local.conf.
p@rick
Am 03.01.2018 um 12:57 schrieb Patrick Ben Koetter p@sys4.de:
- Frank Röhm francwalter@gmx.net:
Am 28.12.2017 um 22:11 schrieb Patrick Ben Koetter p@sys4.de:
DIGEST-MD5 kann prinzipbedingt nicht funktionieren, wenn Du das Kennwort als MD5 abgelegt hast. DIGEST-MD5 gehört zu den Shared-Secret-Mechanismen und die benötigen zwingend, dass das Kennwort unverschlüsselt abgelegt wird.
Kannst Du mir mal folgendes zeigen:
Mach ein "telnet $DEINSERVER 25" und sende den Output von nach dem "EHLO x4db0daba.dyn.telefonica.de" hier auf die Liste. Dann wissen wir, ob Dein Server DIGEST-MD5 anbietet. Das sollte er nämlich nicht, wenn er keine Shared-Secred-Mechanismen verarbeiten kann.
EHLO x4db0daba.dyn.telefonica.de 250-ew6.org 250-PIPELINING 250-SIZE 51200000 250-VRFY 250-ETRN 250-STARTTLS 250-AUTH PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-AUTH=PLAIN DIGEST-MD5 CRAM-MD5 LOGIN 250-ENHANCEDSTATUSCODES 250 8BITMIME
warum bietet mein Postfix da bloß DIGEST-MD5 an, wenn er es nicht kann? Fehlkonfiguriert? Wo schalte ich das ab?
Du nutzt dovecot als PWS, ja? Prüfe mal:
doveconf auth_mechanisms
Wenn da mehr als plain und login im Output steht, dann solltest Du auth_mechanisms anpassen - entweder in der 10-auth.conf oder in der local.conf.
Super, ja, genau das war es ja, hatte es zwischenzeitlich auch selbst gefunden! Vielen DANK!!!
franc
participants (5)
-
Frank Röhm -
Frank Walter
-
Patrick Ben Koetter -
Robert Schetterer -
Walter H.