Ausgangslage
Ich habe meine Mails vom bisherigen Hoster-Postfach (mit SOGo als Webmail) auf ein selbst gehostetes Mailu 2024.06 umgezogen. Mailu läuft per Docker auf meinem VPS, mit TLS_FLAVOR=mail und einem Let's-Encrypt-Zertifikat – und dieses Zertifikat hatte einen ECDSA-Schlüssel. Das wird gleich wichtig. Wie die DNS-Seite des Umzugs aussah, habe ich im Artikel zu Mailu und DNSSEC beschrieben.
Bei mir steht ein Xerox WorkCentre 6515. Darauf ist eine Scan-Zieladresse eingerichtet: Das gescannte Dokument landet per Mail auf einem Alias, den eine Sieve-Regel direkt in einen eigenen Ordner sortiert. Ein kleiner Komfort, den man erst vermisst, wenn er weg ist.
Nach dem Umzug habe ich am Xerox die SMTP-Einstellungen auf den neuen Mailserver umgestellt. Auf dem Gerät lief zu dem Zeitpunkt die Firmware 65.51.61 vom 24.08.2021.
Wie es sich zeigte
Der erste Testscan scheiterte mit „invalid email address“. Im Auftragsprotokoll stand „Abgeschlossen (Fehler)“ mit dem Code 016-767, und der Drucker spuckte zusätzlich einen „Bericht über nicht zugestellte Aufträge“ aus.
Nach einem Neustart des Druckers änderte sich die Fehlermeldung – jetzt hieß es „smtp over ssl failed“.
Zwei verschiedene Fehler für dasselbe Problem? Wie sich herausstellte: zwei verschiedene Probleme hintereinander.
Die Untersuchung
Kommt der Drucker überhaupt bei Mailu an?
Der erste Blick ging in die Mailu-Logs. Mailu schreibt bei mir ins Journal, also:
journalctl -t mailu-smtp -t mailu-frontErgebnis vor dem Druckerneustart: keine einzige Verbindung vom Xerox. Der Drucker meldete also „invalid email address“, ohne jemals mit dem neuen Server gesprochen zu haben.
Parallel habe ich das Auftragsprotokoll des Druckers aus seiner Weboberfläche (EWS, Embedded Web Server) ausgelesen – per Playwright.
DNS?
Naheliegender Verdacht: Der Drucker löst den Namen des neuen Mailservers im Heimnetz falsch auf. Das habe ich mit einem kleinen eigenen Python-Skript geprüft, das gezielt den Router und meinen AdGuard befragt. Beide lieferten die richtige Adresse. DNS war es also nicht.
Nach dem Neustart: endlich ein Fehler auf der Serverseite
Nach dem Neustart des Druckers tauchte der Xerox dann doch im Mailu-Log auf – mit diesem Eintrag auf dem Submission-Port:
submission-login: ... SSL_accept() failed: error:0A0000C1:SSL routines::no shared cipher ... lport=587„no shared cipher“ heißt: Client und Server haben sich im TLS-Handshake auf keine einzige gemeinsame Cipher-Suite einigen können. Die Verbindung kommt an, scheitert aber, bevor überhaupt SMTP gesprochen wird.
In den SSL/TLS-Einstellungen des Druckers waren TLS 1.1 und TLS 1.2 aktiviert, TLS 1.0 aus. An der Protokollversion lag es also nicht – TLS 1.2 können beide.
Welche Ciphers kann eigentlich wer?
Um das sauber zu klären, habe ich beide Seiten mit openssl s_client abgeklopft: eine Schleife über die Cipher-Liste, jeweils mit -tls1_2 und @SECLEVEL=0, damit OpenSSL auch alte Suiten überhaupt anbietet. Sinngemäß so:
for c in $(openssl ciphers 'ALL:@SECLEVEL=0' | tr ':' ' '); do
if echo | openssl s_client -connect <ziel>:<port> -tls1_2 \
-cipher "$c@SECLEVEL=0" >/dev/null 2>&1; then
echo "OK: $c"
fi
doneFür SMTP auf Port 587 kommt noch -starttls smtp dazu.
Beim Drucker habe ich mir einen Trick erlaubt: Den SMTP-Client des Xerox kann man so nicht direkt abfragen. Ich habe deshalb seinen HTTPS-Server auf Port 443 getestet, stellvertretend für das, was der TLS-Stack der Firmware kann. Das Ergebnis:
- Xerox (HTTPS, Port 443), TLS 1.2: AES256-SHA256, AES128-SHA256, AES256-SHA, AES128-SHA
- Mailu (Submission, Port 587), TLS 1.2: ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-ECDSA-AES128-GCM-SHA256
Keine einzige Überschneidung. Der Drucker kann nur Suiten mit RSA-Schlüsselaustausch (kein ECDHE), Mailu bietet nur ECDHE mit ECDSA-Authentifizierung an.
Gibt es neuere Firmware?
Die Frage war dann: Kann der Drucker mit neuerer Firmware mehr? Laut dem Xerox-Dokument „VersaLink Product Enhancements SPAR x.64.51“ gibt es ab Version x.64.51 die Suiten TLS_ECDHE_RSA_WITH_AES_128_GCM und TLS_ECDHE_RSA_WITH_AES_256_GCM – allerdings nicht automatisch, sondern erst nach Eingabe eines Feature Enablement Key. Den Code nennt Xerox in genau diesem Dokument.
Von meiner Version 65.51.61 aus führt der Weg über eine Bridge-Version 65.59.11. Und der WC6515 hat keinen Firmware-Upload in der Weboberfläche – es gibt nur das Windows-Tool FWDLMgr, das die Firmware über Port 9100 an den Drucker schickt.
Die Irrwege
Ein paar Abzweigungen habe ich genommen, bevor das Bild klar war. Sie gehören dazu, weil jede davon zunächst plausibel aussah.
„Die Namensauflösung im Heimnetz ist falsch.“ Bei einem Mailserver-Umzug ist DNS der Klassiker. Die Abfragen gegen Router und AdGuard lieferten aber beide die richtige Adresse – Verdacht widerlegt.
„Der Drucker spricht schon mit Mailu, und Mailu lehnt den Empfänger ab.“ Die Meldung „invalid email address“ legt genau das nahe. Das leere Mailu-Log hat diese Theorie erledigt: Es gab gar keine Verbindung. Der Xerox übernimmt eine geänderte SMTP-Einstellung offenbar erst nach einem Neustart. Bis dahin hat er vermutlich weiter über den alten Mailserver gesendet und von dort die Fehlermeldung bekommen – das ist allerdings gefolgert, das Log des alten Anbieters habe ich nicht geprüft.
„Die Firmware ist von 2019, ein Update ist ungewiss.“ Meine erste Versionsangabe stammte aus dem IPP-Protokoll des Druckers und lautete 1.57.12. Das ist aber nur die Teilversion des Controllers. Die eigentliche Firmware-Version stand in der Weboberfläche: 65.51.61. Erst mit dieser Nummer konnte ich die Xerox-Dokumentation richtig lesen – und feststellen, dass es tatsächlich Firmware mit ECDHE_RSA gibt.
„Dann erlaube ich in Mailu eben die alten Ciphers.“ Klingt nach dem schnellsten Weg. Habe ich aber verworfen, ohne es auszuprobieren: Suiten wie AES128-SHA mit RSA-Schlüsselaustausch setzen ein RSA-Zertifikat voraus. Mit meinem ECDSA-Zertifikat hätte Mailu sie gar nicht anbieten können, egal wie die Cipher-Liste aussieht. Das war eine Analyse, kein Test.
Die Ursache
Es waren zwei Ursachen hintereinander:
- Der Xerox übernimmt geänderte SMTP-Einstellungen erst nach einem Neustart. Bis dahin lief der Versand nicht über Mailu, und die Fehlermeldung „invalid email address“ hatte mit dem neuen Server nichts zu tun.
- Es gab keinen gemeinsamen Cipher. Die alte Firmware kann als Client nur RSA-Schlüsselaustausch (AES-SHA/SHA256, kein ECDHE). Mailu mit ECDSA-Zertifikat bietet nur ECDHE-ECDSA an. Der alte Anbieter hatte beides im Angebot – deshalb ist das Problem dort nie aufgefallen.
Das ist das eigentlich Tückische: Am Drucker hat sich nichts geändert, am neuen Mailserver ist nichts falsch konfiguriert. Erst die Kombination aus moderner Standardkonfiguration und alter Firmware passt nicht zusammen.
Die Lösung
Die Lösung setzt an beiden Enden an: Der Drucker lernt ECDHE_RSA, und Mailu bekommt ein RSA-Zertifikat, damit es ECDHE_RSA überhaupt anbieten kann.
1. Drucker neu starten
Banal, aber notwendig: Nach der SMTP-Umstellung den Xerox am Gerät neu starten. Ohne das redet er gar nicht erst mit dem neuen Server.
2. Firmware einspielen – aus einer Windows-VM
FWDLMgr gibt es nur für Windows. Ich habe dafür eine Windows-11-VM unter libvirt genommen und sie über virsh send-key und Mausklicks per QMP bedient. Nicht elegant, aber es funktioniert.
Mit FWDLMgr 5.3.7 habe ich die Firmware über das Netz in zwei Schritten eingespielt:
- Bridge-Version 65.59.11 (Controller-Version von 1.57.12 auf 1.69.1)
- Danach 65.76.91 (Controller-Version 1.99.0)
3. Feature Enablement Key eingeben
Die neuen Cipher-Suiten sind nach dem Update noch nicht aktiv. Den Freischaltcode aus dem Xerox-Dokument habe ich in der Weboberfläche unter System → Sicherheit → Funktionenaktivierung eingegeben und den Drucker danach neu gestartet. Den Code selbst nenne ich hier nicht – er steht im oben genannten Xerox-Dokument.
4. Mailu-Zertifikat auf RSA umstellen
Damit Mailu ECDHE-RSA-* anbieten kann, braucht es ein RSA-Zertifikat. Ich habe das bestehende Let's-Encrypt-Zertifikat per certbot mit RSA-Schlüssel neu ausstellen lassen:
certbot certonly --cert-name <zertifikatsname> \
-d mx.example.org -d mail.example.org \
--webroot -w /var/www/_letsencrypt \
--key-type rsa --rsa-key-size 2048 \
--force-renewalDanach habe ich meinen Deploy-Hook (mailu-zertifikat.sh) ausgeführt, der das neue Zertifikat an Mailu übergibt.
Vorher habe ich gesichert: cert.pem und key.pem als *.bak-vor-rsa, ebenso die Renewal-Konfiguration von certbot.
Der Nachweis
Drucker: Nach dem Feature Key handelt der Xerox die neue Suite aus:
openssl s_client -connect <drucker-ip>:443 -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256Cipher: ECDHE-RSA-AES128-GCM-SHA256Vorher stand an dieser Stelle nur 0000 – kein Handshake.
Mailu: Das Zertifikat ist jetzt RSA:
openssl x509 -in cert.pem -noout -text | grep "Public Key Algorithm"Public Key Algorithm: rsaEncryptionAuf Port 465 handelt Mailu ECDHE-RSA-AES128-GCM-SHA256 aus, und auf den Ports 993, 587 und 25 meldet openssl s_client jeweils Verify return code: 0 (ok).
Der echte Test: Ein Scan am Drucker. Im Mailu-Log taucht der Xerox jetzt mit SASL-Login auf, und die Mail wird zugestellt:
... orig_to=<scan-adresse@example.org> ... status=sent (250 2.0.0 ... Saved)Die Sieve-Regel hat die Mail wie vorgesehen abgelegt – Scan-to-Mail funktioniert wieder.
Was offen bleibt
Bleibt das Zertifikat RSA? In der Renewal-Konfiguration steht jetzt key_type = rsa. Ob die automatische Verlängerung das wirklich beibehält, habe ich noch nicht nachgeprüft. Wenn certbot irgendwann wieder ein ECDSA-Zertifikat ausstellt, ist der Drucker sofort wieder raus.
Fazit
Wenn ein älteres Gerät nach einem Mailserver-Umzug plötzlich keine Mails mehr verschickt, lohnt sich ein Blick auf beide Seiten des TLS-Handshakes. Die Cipher-Listen mit openssl s_client aufzuzählen zeigt sofort, ob es überhaupt eine Schnittmenge gibt.
Und zwei Lehren speziell aus diesem Fall: Ein ECDSA-Zertifikat schließt Clients aus, die nur RSA-Schlüsselaustausch beherrschen – egal, wie großzügig die Cipher-Liste ist. Und bei Xerox-Druckern gilt: Nach einer Änderung an den SMTP-Einstellungen erst neu starten, dann Fehler suchen.
Anzeige · Affiliate-Link – kaufst du darüber, erhalte ich ggf. eine Provision. Für dich ändert sich am Preis nichts.
