SNI SSL Zertifikate für Mail

Ich glaube das sind die mit dem 5 Buchstaben.
Wir haben das SNI-Thema für Postfix durchaus im Auge.
Aus rein technischer Sicht sehe ich keinen Mehrwert dadurch (aus dem selben Grund wurde dieses Feature ja auch jahrelang nicht implementiert...). Ich bin immer an Use-Cases interessiert, aber "Leute die es nicht schaffen ihre Postfächer richtig einzurichten" schaffen das dann mit einem eigenen Mail-Domainnamen auch nicht besser (die Energie für solche Kunden sollte man lieber in AutoConfigure/AutoDiscover investieren). Zudem unterstützen auch noch nicht alle Mail-Clients SNI entsprechend, was also letztendlich zu noch mehr Problemen führen kann (z.B. bei alten Outlook- oder Android-Versionen).

Aber zurück zum Thema: Debian 10 kommt mit Postfix 3.4 und würde das prinzipiell unterstützen.
Das größte Problem sehe ich in den SSL-Zertifikaten selbst. Da die meisten Anwender vermutlich gerne kostenfreie Zertifikate dafür nutzen möchten, müssen die Domains ("mail.example.org") automatisiert validiert werden. In Multiserver-Konfigurationen mit separatem Mailserver wird das durchaus kompliziert, da dort nicht zwangweise ein Webserver (für HTTP-Validierung) läuft.
Eine Idee hier ist, dass SNI angeboten wird, wenn alle Bedingungen für eine "einfache" HTTP-Validierung erfüllt sind (also u.a. dass auf dem Mailserver irgendein von LiveConfig gemanagter Webserver läuft).

Den Vorteil, dass der Kunde dann verschlüsselt mit "mail.<kundendomain>" arbeiten kann, erkauft man aber mit dem Nachteil, dass noch mehr SSL-Zertifikate verwaltet (validiert/aktualisiert) werden müssen - die Gesamtkomplexität und somit die Wahrscheinlichkeit für Probleme wird also meiner Einschätzung nach eher größer als kleiner.
Auch DANE/TLSA lässt sich mit einer "zentralen" Mail-Subdomain wesentlich einfacher handhaben...

Zitat von kk

die Energie für solche Kunden sollte man lieber in AutoConfigure/AutoDiscover investieren

Sehe ich persönlich auch so.

Insbesondere erhöhen die eigenen Subdomains dann auch den Support-Aufwand ("bei Kollege A geht's - ich erhalte komische Fehler!" "du hast auch Eudora Mail von 2006 im Einsatz, der Kollege nutzt den neuesten Thunderbird, der SNI unterstützt").

Grundsätzliche Zustimmung an KK and antondollmaier - für Reselling / Whitelabeling / ... wäre das Feature wiederum sehr interessant, sehe es aber nicht vorne auf der Liste der wichtigen Dinge (und Bugs).

Zitat von Mogwais

Das Problem mit den nicht umziehen können ohne viele Endgeräte anzufassen bleibt so aber trotzdem.

Wo genau soll "Kunde nutzt mail.example.com als IMAP-Server" helfen?

- Office365 hat gar kein IMAP, zumindest nicht per Default. Den tatsächlichen IMAP-Server gibt's nur via Autodiscover.
- GMail nutzt immer "imap.gmail.com". Egal, welche Kunden-Domain das ist.
- die Migration auf einen lokalen Exchange-Server sieht nochmal komplett anders aus.

"White-Label-Reselling" endet spätestens beim Netzwerk (WHOIS!), meistens schon früher (VM-Host, ReverseDNS).

Komisch auch, dass solche Feature-Requests nur an uns "kleine" rangetragen werden. Oder hat sich schon mal jemand bei Microsoft beschwert, warum "autodiscover.outlook.com" nicht als Whitelabel existiert?

Danke, ganz meine Meinung. Ich kommentiere das immer mit einem dezenten Verweis auf Kosten/Budget. Dann hat sich das meist schnell erledigt

Zitat von antondollmaier

Wo genau soll "Kunde nutzt mail.example.com als IMAP-Server" helfen?

- Office365 hat gar kein IMAP, zumindest nicht per Default. Den tatsächlichen IMAP-Server gibt's nur via Autodiscover.
- GMail nutzt immer "imap.gmail.com". Egal, welche Kunden-Domain das ist.
- die Migration auf einen lokalen Exchange-Server sieht nochmal komplett anders aus.

"White-Label-Reselling" endet spätestens beim Netzwerk (WHOIS!), meistens schon früher (VM-Host, ReverseDNS).

Komisch auch, dass solche Feature-Requests nur an uns "kleine" rangetragen werden. Oder hat sich schon mal jemand bei Microsoft beschwert, warum "autodiscover.outlook.com" nicht als Whitelabel existiert?

Alles anzeigen