KeyHelp: E-Mail-Programme mit Autokonfiguration einrichten (Thunderbird, Outlook, iPhone)

Kunden sollen ihre Postfächer in Thunderbird, Outlook oder auf dem iPhone einrichten können, ohne Servernamen und Ports abzutippen. KeyHelp bringt dafür eine Autokonfiguration mit, die drei Verfahren bedient: das Mozilla-Format für Thunderbird, Autodiscover für Outlook und ein Konfigurationsprofil für Apple-Geräte. Diese Anleitung zeigt, wo KeyHelp die Daten ausliefert, welche Admin-Einstellung den Servernamen bestimmt, warum dafür ein Zertifikat an der Domain hängen muss und wie Sie jede Antwort auf dem Server selbst prüfen. Sie richtet sich an Administratoren eines Servers wie in KeyHelp installieren und absichern. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12. Die Mailprogramme selbst haben wir nicht getestet, sondern die Antworten des Servers.

Voraussetzungen

• KeyHelp mit Admin-Zugang, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.
• Ein Postfach, im Beispiel info@kunde1.example.de.
• DNS-Einträge für autoconfig, autodiscover und autoconfig-apple unter der Kundendomain, die auf den Server zeigen. Liegt die Zone auf dem KeyHelp-Server, deckt der Standard-Eintrag * A das bereits ab.
• Ein gültiges Zertifikat für den Servernamen, den die Clients bekommen, sonst sehen Kunden Zertifikatswarnungen. Wie Sie Zertifikate einrichten, zeigt KeyHelp: SSL-Zertifikate mit Let's Encrypt.
• SSH-Zugang für die Prüfung mit curl und openssl.

Schritt 1: Verstehen, wie KeyHelp die Anfragen beantwortet

KeyHelp legt in /etc/apache2/keyhelp/autoconfig.conf einen eigenen Virtual Host auf Port 80 an:

ServerName autoconfig
ServerAlias autoconfig.* autodiscover.* autoconfig-apple.*
DocumentRoot /home/keyhelp/www/keyhelp/misc/emailconfig

Er greift für jede Domain auf dem Server, ohne dass Sie pro Kunde etwas anlegen. Eine .htaccess im Verzeichnis leitet die drei Formate an dasselbe Skript emailconfig.php weiter und kommentiert sie mit „Mozilla“ (config-v1.1.xml), „Microsoft“ (autodiscover.xml) und „Apple“ (.mobileconfig). Zusätzlich enthält keyhelp.conf für die Panel-Domain die Aliase /autoconfig und /autodiscover.

Verifizieren: Fragen Sie die Thunderbird-Konfiguration ab. Mit --resolve testen Sie auch ohne öffentliches DNS:

curl -s --resolve autoconfig.kunde1.example.de:80:127.0.0.1 \
  "http://autoconfig.kunde1.example.de/mail/config-v1.1.xml?emailaddress=info@kunde1.example.de"

Die Antwort ist ein clientConfig-XML mit IMAP auf 993 (SSL) und 143 (STARTTLS), POP3 auf 995 und 110, SMTP auf 465, 587 und 25 sowie <username>%EMAILADDRESS%</username>. Als Server stand ab Werk server.example.de darin, der Hostname des Servers.

Schritt 2: Den Servernamen für die Clients festlegen

Öffnen Sie „Konfiguration“ und „E-Mail-Server“. Im Abschnitt „Verbindungsdaten“ wählen Sie unter „Hauptdomain für die Verbindung von E-Mail-Clients“ eine von drei Optionen:

• „Verwende den Hostnamen des Servers“ (Standard): Alle Kunden verbinden sich mit dem Hostnamen. Am einfachsten, ein Zertifikat für den Hostnamen genügt.
• „Verwende den zugehörigen Domain-Namen“: Jeder Kunde bekommt seine eigene Domain als Servernamen. Laut Formular muss die Domain „SSL/TLS-gesichert sein“, sonst nimmt KeyHelp den Hostnamen.
• „Verwende eine benutzerdefinierte Domain“: eine feste, SSL-geschützte Domain für alle.

Im Test haben wir „Verwende den zugehörigen Domain-Namen“ gewählt. Solange kunde1.example.de kein Zertifikat hatte, blieb in der Antwort server.example.de, genau wie beschrieben. Erst nachdem wir der Domain im Reiter „Sicherheit“ ein Zertifikat zugewiesen hatten, stand dort <hostname>kunde1.example.de</hostname>.

Wichtig ist, was KeyHelp dabei im Hintergrund tut: Es schreibt die Domain mit ihrem Zertifikat in /etc/dovecot/dovecot-sni.conf (local_name kunde1.example.de { … }) und in /etc/postfix/postfix-sni.conf, die Postfix über tls_server_sni_maps liest. IMAP, POP3 und SMTP liefern so je nach angefragtem Namen das passende Zertifikat aus.

Verifizieren: Prüfen Sie, welches Zertifikat ein Client bei der Kundendomain sieht:

echo | openssl s_client -connect 127.0.0.1:993 -servername kunde1.example.de 2>/dev/null \
  | openssl x509 -noout -subject

Der Name im Zertifikat muss zum Servernamen der Autokonfiguration passen. Im Test hatten wir der Domain bewusst das Standardzertifikat default zugewiesen, das nur CN = server.example.de enthält. Für den Echtbetrieb gehört an die Domain ein Zertifikat, das ihren Namen enthält, etwa von Let's Encrypt.

Schritt 3: Thunderbird

Thunderbird fragt nach dem Mozilla-Format, das KeyHelp unter http://autoconfig.DOMAIN/mail/config-v1.1.xml beantwortet. Der Kunde gibt Name, E-Mail-Adresse und Passwort ein, den Rest füllt die Antwort aus Schritt 1. Als Benutzername dient die volle E-Mail-Adresse.

Über HTTPS lieferte https://autoconfig.kunde1.example.de/… im Test einen 404, weil der Autoconfig-Host nur auf Port 80 eingerichtet ist. Auch https://kunde1.example.de/.well-known/autoconfig/mail/config-v1.1.xml ergab nach einer Umleitung auf HTTP einen 404. Ob Thunderbird dann auf die HTTP-Adresse zurückfällt, hängt vom Programm ab. Das haben wir nicht mit Thunderbird selbst geprüft.

Verifizieren: Der curl-Aufruf aus Schritt 1 liefert HTTP 200 mit Content-Type: text/xml;charset=UTF-8 und dem erwarteten Hostnamen.

Schritt 4: Outlook über Autodiscover

Outlook sendet eine XML-Anfrage per POST an autodiscover.DOMAIN/autodiscover/autodiscover.xml. KeyHelp antwortet auf Port 80 mit einer Umleitung auf die Panel-Domain:

LOCATION: https://server.example.de/Autodiscover/Autodiscover.xml?domain_name=kunde1.example.de

Dort kommt per POST eine Autodiscover-Antwort mit allen Protokollen, Ports und <LoginName>info@kunde1.example.de</LoginName>. Ein einfacher GET ohne XML-Anfrage beantwortet KeyHelp mit <ErrorCode>600</ErrorCode>. Für den Test brauchen Sie deshalb eine kleine XML-Datei mit der E-Mail-Adresse als Anfrage.

curl -s -i --resolve autodiscover.kunde1.example.de:80:127.0.0.1 -X POST \
  -H "Content-Type: text/xml" --data @anfrage.xml \
  "http://autodiscover.kunde1.example.de/autodiscover/autodiscover.xml"

Auffällig: In der Autodiscover-Antwort stand auch nach der Umstellung aus Schritt 2 in allen sieben <Server>-Einträgen server.example.de, nicht die Kundendomain. Outlook-Nutzer verbinden sich also mit dem Hostnamen. Damit es keine Warnung gibt, braucht der Hostname ein gültiges Zertifikat, und die Panel-Domain muss per HTTPS erreichbar sein. Direkt per HTTPS an autodiscover.kunde1.example.de oder kunde1.example.de/autodiscover/… kam im Test ein 404.

Verifizieren: Die POST-Anfrage an die Umleitungsadresse liefert HTTP 200 und Protokolle mit <Type>imap</Type>, <Port>993</Port> und <SSL>on</SSL>.

Schritt 5: iPhone und Mac mit Konfigurationsprofil

Für Apple-Geräte erzeugt KeyHelp ein Profil. Der Kunde öffnet im Kundenbereich unter „E-Mail-Adressen“ in der Spalte „Verbindungsdaten“ den Link „Anzeigen“. Der Dialog bietet „IMAP-Konto einrichten“ und „POP3-Konto einrichten“, jeweils mit „QR-Code anzeigen“. KeyHelp empfiehlt, die Links „mit dem Safari-Browser“ zu öffnen. Darunter steht unter „Manuelle Konfiguration“ alles für Programme ohne Autokonfiguration.

Die Links zeigen auf http://autoconfig-apple.kunde1.example.de/setup.mobileconfig?email=info@kunde1.example.de&protocol=imap. Die Antwort kommt mit Content-Disposition: attachment; filename="setup.mobileconfig" und enthält Server, Ports, SSL und die Adresse als Benutzernamen. Das Passwortfeld IncomingPassword ist leer, das iPhone fragt beim Installieren danach. In der Antwort fanden wir keine Signatur, das Profil ist also unsigniert. Mit dem Domainnamen aus Schritt 2 stand im Profil kunde1.example.de als Server.

Verifizieren:

curl -s --resolve autoconfig-apple.kunde1.example.de:80:127.0.0.1 \
  "http://autoconfig-apple.kunde1.example.de/setup.mobileconfig?email=info@kunde1.example.de&protocol=imap" \
  | grep -A1 IncomingMailServerHostName

Typische Fehler

Clients bekommen den Hostnamen statt der Kundendomain

Steht trotz „Verwende den zugehörigen Domain-Namen“ der Hostname in der Antwort, fehlt der Domain das Zertifikat. Weisen Sie es im Reiter „Sicherheit“ der Domain zu, nach rund einer halben Minute ändert sich die Antwort. Für Outlook bleibt es beim Hostnamen.

Zertifikatswarnung im Mailprogramm

Der Servername aus der Autokonfiguration steht nicht im Zertifikat. Prüfen Sie mit openssl s_client … -servername aus Schritt 2, welches Zertifikat ausgeliefert wird.

Versand ohne Verschlüsselung scheitert

Wer im Mailprogramm Port 587 ohne STARTTLS einstellt, kann sich nicht anmelden. swaks meldete im Test „Host did not advertise authentication“. Mit TLS auf 465 kam „235 2.7.0 Authentication successful“.

Anleitung nennt mail.DOMAIN als Server

Die Keyweb-Wissensdatenbank (Artikel „Allgemeine E-Mail-Client Konfiguration“, Stand 2017) nennt mail.<IHRE_DOMAIN> als Server. KeyHelp 26.1.1 gibt in Autokonfiguration und Kundenbereich dagegen den Hostnamen oder, je nach Einstellung, die Domain selbst aus. Richten Sie sich nach dem Dialog „Verbindungsdaten“.

Autokonfiguration findet nichts

Meist fehlen die DNS-Namen autoconfig, autodiscover oder autoconfig-apple, weil die Zone beim Domain-Anbieter liegt. Legen Sie dort A-Einträge auf die Server-IP an.

Häufige Fragen

Antwortet KeyHelp auch für nicht existierende Adressen?

Ja. Eine Anfrage für gibtsnicht@kunde1.example.de bekam dieselbe Konfiguration. Die Autokonfiguration prüft nicht, ob das Postfach existiert, verrät also auch keine gültigen Adressen.

Welche Ports soll ich Kunden empfehlen?

Für IMAP 993 und für den Versand 465, beide mit SSL/TLS ab der ersten Verbindung. Die STARTTLS-Varianten 143 und 587 funktionieren ebenfalls. POP3 nur, wenn ein Kunde Mails bewusst vom Server holen und dort löschen will.

Muss ich für jeden Kunden etwas einrichten?

Nein. Der Autoconfig-Host gilt für alle Domains, nötig sind nur DNS und, für eigene Servernamen, ein Zertifikat pro Domain.

Was zeigt der Kundenbereich bei mehreren Servernamen?

Mit der Option „Zeige alle Domains im Verbindungsdaten-Fenster an, die als Servernamen verwendet werden können“ listete der Dialog im Test unter „Alternative Server“ zusätzlich server.example.de.

Testumfang

Wir haben auf KeyHelp 26.1.1 die Antworten für Thunderbird, Outlook und Apple mit curl abgefragt, die Einstellung „Verbindungsdaten“ umgestellt und Zertifikate per openssl geprüft. Auffällig: Outlook bekommt immer den Hostnamen, HTTPS-Anfragen an die Autoconfig-Namen enden mit 404. Echte Mailprogramme und Geräte haben wir nicht getestet. Richten Sie zum Abschluss ein Testkonto in Ihrem Mailprogramm ein.

Fazit

Die Autokonfiguration in KeyHelp funktioniert ohne Einrichtung pro Kunde. Ihre Arbeit liegt bei DNS und Zertifikaten: Die drei Autoconfig-Namen müssen auf den Server zeigen, und der Servername, den die Clients bekommen, braucht ein passendes Zertifikat. Wer Kunden eigene Servernamen geben will, stellt auf „Verwende den zugehörigen Domain-Namen“ um und versorgt jede Domain mit Let's Encrypt. Für Outlook sollte der Hostname immer ein gültiges Zertifikat haben.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern: das kostenlose Hosting-Panel für eigene Server
• KeyHelp: SSL-Zertifikate mit Let's Encrypt und eigener CA einrichten und überwachen
• KeyHelp: SPF, DKIM und DMARC für Kundendomains einrichten und prüfen
• KeyHelp Knowledge Base: Allgemeine E-Mail-Client Konfiguration
• KeyHelp Changelog (Keyweb)
• Keyweb: KeyHelp, alle Funktionen im Überblick