Hallo zusammen.
"DATEV ist schuld" -> dem ist in diesem speziellen Fall nichts hinzuzufügen ...
Was ist passiert?
Mailserver sollen aus Kundensicht einfach nur funktionieren. Bei Uploadmail gibt es eine besondere Anforderung: Mails, die via Uploadmail bei DATEV ankommen, müssen auf dem letzten Meter transportverschlüsselt sein. Ansonsten wird die Mailannahme abgelehnt. Es erfolgt kein Fallback auf Klartextübertragung.
Mailserver sollten aber auch aktuelle Verschlüsselung anbieten. Das "aktuell" ist hier der Grund, warum immer mal wieder nachjustiert werden muss. Einen Mailserver einmal aufsetzen und dann 10 Jahre laufen lassen - das klappt irgendwann nicht mehr ... Mailserverbetreiber müssen also hin und wieder Änderungen am Mailsystem vornehmen.
Vor einigen Wochen wurden z.B. alle Mailserver bei DATEV um 2 Versionsnummern aktualisiert. Hat keiner gemerkt. Aber damit steht nun prinzipiell richtig moderne Verschlüsselung zur Verfügung.
Auf der anderen Seite müssen wir weiterhin Verschlüsselungsmethoden unterstützen, die schon abgehangen sind und auch Welche, die mittlerweile als "schwach" eingestuft werden. Also haben wir in den letzten Wochen akribisch ausgewertet, welche Verschlüsselungsmethoden der Mailserver für Uploadmail anbietet (39!) und welche davon wirklich benutzt werden (9!)
Also wurde das "Angebot" ausgedünnt. LEIDER ist mir dabei ein Fehler unterlaufen: Ich habe 2 Verschlüsselungsmethoden übersehen. So war ab Montag ca. 9 Uhr der "Blumenstrauß an Verschlüsselungsmethoden von 39 auf 11 reduziert. Aber es fehlten immer noch 2. Diese 2 fehlenden Methoden waren die Ursache für die Diskussionen hier. Dienstag ca. 15 Uhr habe ich dann mit einer Rolle rückwärts erstmal wieder den alten Stand aktiviert.
Inzwischen habe ich mich wieder und wieder durch unsere Logs gewühlt. Herausgekommen ist Folgendes (alle Zahlen beziehen sich auf die letzten 7 Tage):
- ca. 2,7 Mio. TLS 1.3 Verbindungen. Diese gelten als modern und sind unkritisch.
- ca. 196k TLS 1.2 Verbindungen, davon
- 195k ebenfalls mit Verschlüsselungsmethoden, die als modern gelten und unkritisch sind
- 185x ECDHE-RSA-AES256-SHA384
- 42x DHE-RSA-AES256-SHA256
- 27x ECDHE-ECDSA-AES256-SHA
- 2x AES256-GCM-SHA384
Und die beiden Methoden, die hier mit ECDHE anfangen hatte ich fälschlicherweise übersehen und deaktiviert. Damit sind etwas mehr als 200 Mailverbindungen nicht zustande gekommen. Zudem hatte ich nicht auf dem Radar, welche Bedeutung der 10. eines Monats hat. Diese Lektion habe ich nun gelernt ...
Wie geht's nun weiter?
Ich würde gern wissen, ob diesmal meine Zahlen stimmig sind. Rückmeldungen hier sind willkommen!
Wir werden einen neuen Anlauf unternehmen, die 39 Verschlüsselungsmethoden einzudampfen. Diesmal aber so, dass wirklich keiner beeinträchtigt wird. Ein Termin dafür steht noch nicht fest, wird aber sicher über die normalen Kommunikationskanäle angekündigt werden.
Dann werden die Kunden, die alte Verschlüsselungsmethoden benutzen, separat angeschrieben. Mit ausreichend Vorlauf wollen wir die obigen 4 Methoden deaktivieren, wenn sie nicht mehr benutzt werden. Das kann aber sicher bis Anfang 2026 dauern. Uns ist klar, dass ein Mailserverupdate - und das ist hier in den meisten Fällen nötig - langfristig geplant werden muss. Wir kennen das ...
Aber: es muss getan werden.
Abschließend möchte ich auch gleich noch eine Änderung ankündigen, von der wir wieder meinen, dass die niemanden treffen wird. Im DNS steht aktuell „Mails an @uploadmail.datev.de sind an den Server ‚duo-mail.datev.de' zu senden “. Dieser Name ist vor vielen Jahren gewählt worden, passt aber heutzutage nicht mehr sonderlich gut in unser Betriebskonzept. Daher wird (vorbehaltlich einer internen Genehmigung) am Mittwoch, den 17. September 2025 nach 18 Uhr der MX-Eintrag auf ‚mailin.uploadmail.datev.de‘ geändert. Gleiches System, passendes Zertifikat, neuer Name. Ausfälle sind nicht zu erwarten. Wenn doch Probleme bekannt werden, ist eine DNS-Änderung auf den alten Wert auch wieder zeitnah möglich.
In dem Sinne: Grüße aus dem Maschinenraum und nochmal: Sorry! Mein Fehler.
