Kaum denkt man, man hat den neuen Heimserver einigermaßen am Laufen – der suck-Job für den frisch aufgesetzten INN läut übrigens immer – fangen die Probleme auch schon an. 😉 Besagter Heimserver dient bei mir unter anderem dazu, via IMAP die E-Mails für die Familie vorzuhalten. Dazu setze ich „schon immer“ Courier ein, da die Postfächer auch von außerhalb zugänglich sein sollen, in der Spielart courier-imap-ssl, also mit SSL-Verschlüsselung. Als Clients verwende ich zumindest familienintern ausschließlich Thunderbird. Bei meinem eigenen Thunderbird war das auch kein Problem, der hatte sich sofort und, abgesehen vom neuen SSL-Zertifikat, ohne Murren mit dem frisch aufgesetzten IMAP-Server verbunden. Stutzig gemacht hat mich allerdings heute, dass sich eine zweite Thunderbird-Installation überhaupt nicht mit dem neuen Server verbinden wollte – und das komplett ohne Fehlermeldung.
Fündig geworden bin ich dann nach einiger Suche in /var/log/syslog bzw. /var/log/mail.err, wo sich die eher unscheinbaren Zeilen nach folgendem Muster fanden:
Jul 2 14:09:09 tigersclaw imapd-ssl: couriertls: accept: error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter |
Eine Google-Suche brachte mich dann einen Schritt weiter: Courier ist leider von Debian aus sozusagen ab Werk dahingehend fehlkonfiguriert, dass es viel zu kurze Diffie-Hellman-Parameter erzeugt, die unter anderem von Thunderbird als zu unsicher verworfen werden. Höchst bedauerlich finde dabei übrigens, dass Thunderbird das dem Nutzer nicht vernünftig mitteilt, sondern einfach gar nichts tut. Die Lösung des Problems ist aber relativ simpel: man erzeugt einfach eine neue Datei /etc/courier/dhparams.pem mit längeren DH-Parametern. Wie im oben verlinkten Blogbeitrag beschrieben, geht das bei Debian eigentlich auch relativ bequem und automatisiert durch den Aufruf von DH_BITS=2048 mkdhparams in der Shell. Dummerweise verbirgt sich hinter mkdhparams aber ein Shell-Skript, das im ersten Schritt zunächst prüft, ob die DH-Parameter-Datei älter oder jünger als 25 Tage ist und im letzteren Fall kommentarlos abbricht. Da mein Server aber gerade frisch aufgesetzt war, war die Datei natürlich deutlich jünger als 25 Tage. Nachdem ich auch diesen Rätsel gelöst hatte 😉 , half dann das Löschen bzw. Umbenennen von /etc/courier/dhparams.pem und das anschließende Ausführen von mkdhparams. Danach noch ein Neustart des courier-imap-ssl-Daemons und alles funktionierte wieder wie gewohnt. 🙂
Aber warum nun funktionierte „mein“ Thunderbird auf Anhieb, der andere aber nicht? Nun, mein Thunderbird ist aufgrund einiger von mir nicht gewünschten Features und Veränderungen sowie Inkompatibilitäten in neueren Versionen noch eine relativ alte Version 31.7. Die andere Thunderbird-Installation hingegen ist brandaktuell in der Version 45.2.0. Offensichtlich hat Mozilla irgendwo dazwischen eine schärfere Prüfung der Verschlüsselungen eingeführt.