Autokonfiguration für die Mail-Domain: SRV, Autoconfig und Autodiscover

Eine Mailadresse und ein Passwort – mehr sollte ein Nutzer beim Einrichten seines Mailkontos eigentlich nicht eingeben müssen. IMAP-Host, Submission-Server, Ports, TLS-Modus und Benutzername kann der Client selbst ermitteln.

In der Praxis gibt es dafür allerdings keinen universellen Mechanismus. Stattdessen existieren mehrere Verfahren, deren Unterstützung vom jeweiligen Client, dessen Version und teilweise sogar vom Betriebssystem abhängt:

Die drei Verfahren können parallel angeboten werden. Sie ergänzen sich, garantieren aber auch zusammen nicht, dass sich jeder Client vollständig automatisch konfigurieren lässt.

SRV-Records nach RFC 6186 und RFC 8314

SRV-Records veröffentlichen, unter welchem Host und Port ein bestimmter Dienst erreichbar ist. Für eine Domain, die ausschließlich verschlüsseltes IMAP sowie beide gängigen Varianten der SMTP-Submission anbietet, könnte die Zone so aussehen:

_imaps._tcp.example.com.        SRV 0 0 993 mail.example.com.
_submissions._tcp.example.com.  SRV 0 0 465 mail.example.com.
_submission._tcp.example.com.   SRV 0 0 587 mail.example.com.

_imap._tcp.example.com.         SRV 0 0 0 .
_pop3._tcp.example.com.         SRV 0 0 0 .
_pop3s._tcp.example.com.        SRV 0 0 0 .

Die vier Zahlen beziehungsweise Werte hinter SRV stehen für:

1. Priorität
2. Gewicht
3. Port
4. Ziel-Host

Bei nur einem Server reichen Priorität und Gewicht 0. Mehrere Einträge mit unterschiedlichen Prioritäten oder Gewichten werden erst interessant, wenn Du Failover oder Load-Balancing abbilden möchtest.

Die Service-Namen bedeuten:

• _imaps: IMAP mit implizitem TLS, normalerweise Port 993
• _submissions: SMTP Submission mit implizitem TLS, normalerweise Port 465
• _submission: SMTP Submission mit STARTTLS, normalerweise Port 587
• _imap: unverschlüsselter Verbindungsaufbau auf Port 143, optional mit STARTTLS
• _pop3 und _pop3s: POP3 ohne beziehungsweise mit implizitem TLS

_submissions wurde mit RFC 8314 ergänzt. Der RFC empfiehlt implizites TLS für Mailzugriffe und Submission gegenüber einem zunächst unverschlüsselten Verbindungsaufbau mit anschließendem STARTTLS.

Trotzdem ist es sinnvoll, zusätzlich _submission auf Port 587 anzubieten. Nicht jeder Client unterstützt _submissions, und manche Programme erwarten für den Mailversand weiterhin Port 587 mit STARTTLS.

Einen Dienst ausdrücklich deaktivieren

Ein einzelner Punkt als Ziel bedeutet, dass der betreffende Dienst nicht angeboten wird:

_pop3._tcp.example.com. SRV 0 0 0 .

Das ist eindeutiger, als den Record einfach wegzulassen. Ein fehlender Record kann schließlich auch bedeuten, dass der Client selbst nach einer passenden Standardkonfiguration suchen soll.

Das SRV-Ziel darf kein CNAME sein

Das Target eines SRV-Records muss ein Hostname mit eigenen A- oder AAAA-Records sein. Ein CNAME ist an dieser Stelle laut RFC 2782 nicht zulässig.

Korrekt:

mail.example.com. A     192.0.2.10
mail.example.com. AAAA  2001:db8::10

_imaps._tcp.example.com. SRV 0 0 993 mail.example.com.

Nicht standardskonform wäre:

mail.example.com. CNAME mail.provider.example.
_imaps._tcp.example.com. SRV 0 0 993 mail.example.com.

Du kannst als SRV-Target stattdessen direkt einen vom Provider vorgegebenen Hostnamen verwenden, sofern dieser selbst über A- oder AAAA-Records erreichbar ist:

_imaps._tcp.example.com. SRV 0 0 993 imap.provider.example.

Der Ziel-Host endet in einer klassischen Zonendatei mit einem Punkt. Ohne diesen Punkt ergänzt der DNS-Server unter Umständen noch den aktuellen Zonennamen.

Zertifikate bleiben notwendig

SRV-Records ersetzen keine TLS-Zertifikate. Der in DNS veröffentlichte Mailserver muss weiterhin ein gültiges Zertifikat präsentieren.

Für eine möglichst breite Client-Kompatibilität sollte das Zertifikat den veröffentlichten Hostnamen im Subject Alternative Name enthalten. Verweist die Konfiguration auf mail.example.com, sollte das Zertifikat also auch für mail.example.com gültig sein.

Die Records kannst Du mit dig prüfen:

dig +short SRV _imaps._tcp.example.com
dig +short SRV _submissions._tcp.example.com
dig +short SRV _submission._tcp.example.com

Eine typische Antwort sieht so aus:

0 0 993 mail.example.com.

Thunderbird: Mozilla Autoconfig

Thunderbird verwendet ein eigenes XML-Format. Für die Domain example.com sind vor allem diese beiden HTTPS-Endpunkte relevant:

https://autoconfig.example.com/mail/config-v1.1.xml
https://example.com/.well-known/autoconfig/mail/config-v1.1.xml

Thunderbird hängt normalerweise zusätzlich die eingegebene Mailadresse als Query-Parameter an:

https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=user@example.com

Bei einer statischen Datei ist das kein Problem. nginx und andere Webserver liefern dieselbe Datei unabhängig vom Query-String aus.

Aktuelle Thunderbird-Versionen bevorzugen HTTPS. Abhängig von den Einstellungen des Clients können zusätzlich HTTP-Varianten versucht werden. Diese solltest Du nicht absichtlich anbieten: Die Konfiguration enthält zwar kein Passwort, bestimmt aber, zu welchen Servern der Client später seine Zugangsdaten sendet.

Erst wenn die providerseitigen Endpunkte keine brauchbare Antwort liefern, kommen weitere Quellen wie Mozillas ISPDB, die Domain des MX-Providers und heuristisch ermittelte Hostnamen ins Spiel.

Die Datei config-v1.1.xml

Eine minimale Konfiguration für IMAP und SMTP Submission mit implizitem TLS sieht so aus:

<?xml version="1.0" encoding="UTF-8"?>
<clientConfig version="1.1">
  <emailProvider id="example.com">
    <domain>example.com</domain>

    <displayName>Example Mail</displayName>
    <displayShortName>Example</displayShortName>

    <incomingServer type="imap">
      <hostname>mail.example.com</hostname>
      <port>993</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </incomingServer>

    <outgoingServer type="smtp">
      <hostname>mail.example.com</hostname>
      <port>465</port>
      <socketType>SSL</socketType>
      <authentication>password-cleartext</authentication>
      <username>%EMAILADDRESS%</username>
    </outgoingServer>
  </emailProvider>
</clientConfig>

socketType kennt unter anderem diese Werte:

• SSL: implizites TLS, etwa auf Port 993 oder 465
• STARTTLS: zunächst normale Verbindung, anschließend Upgrade auf TLS
• plain: unverschlüsselte Verbindung

password-cleartext bedeutet nicht, dass Thunderbird das Passwort unverschlüsselt über das Netzwerk sendet. Gemeint ist eine normale Passwortauthentifizierung wie SASL PLAIN oder LOGIN innerhalb der bereits TLS-geschützten Verbindung.

Entscheidend ist deshalb, dass socketType tatsächlich eine verschlüsselte Verbindung erzwingt.

Für den Benutzernamen stehen unter anderem diese Platzhalter zur Verfügung:

Die meisten modernen Mailserver verwenden die vollständige Mailadresse als Login, weshalb %EMAILADDRESS% normalerweise die richtige Wahl ist.

Das Attribut id ist eine eindeutige Kennung für den Provider. Als Wert bietet sich die primäre Domain an. Entscheidend für die Zuordnung sind jedoch die <domain>-Einträge. Ein Provider kann dort auch mehrere Domains aufführen.

Microsoft Autodiscover

Microsoft Autodiscover stammt aus dem Exchange-Umfeld. Das sogenannte POX-Format kann auch IMAP- und SMTP-Einstellungen beschreiben, wird von aktuellen Outlook-Varianten aber nicht überall gleich behandelt.

Das ist ein wichtiger Unterschied zu Thunderbird Autoconfig: Ein syntaktisch korrekter Autodiscover-Endpunkt bedeutet noch nicht automatisch, dass jede Outlook-Version daraus ein generisches IMAP-Konto anlegt.

Teste den Ablauf deshalb mit genau den Outlook-Versionen und Plattformen, die Deine Nutzer einsetzen.

Typische Endpunkte

Autodiscover-Clients können unter anderem diese URLs anfragen:

https://autodiscover.example.com/Autodiscover/Autodiscover.xml
https://example.com/Autodiscover/Autodiscover.xml

Zusätzlich lässt sich ein SRV-Record veröffentlichen:

_autodiscover._tcp.example.com. SRV 0 0 443 autodiscover.example.com.

Der SRV-Record enthält nur Host und Port. Der Pfad /Autodiscover/Autodiscover.xml wird vom Client ergänzt.

Da HTTP-Pfade auf Linux-Webservern zwischen Groß- und Kleinschreibung unterscheiden, ist es sinnvoll, sowohl die von Microsoft dokumentierte Schreibweise als auch die komplett kleingeschriebene Variante zu bedienen.

Autodiscover verwendet POST

Anders als bei Thunderbird wird die Konfiguration normalerweise per HTTP-POST angefordert. Der Request enthält die Mailadresse und das gewünschte Antwortschema:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>alice@example.com</EMailAddress>
    <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
  </Request>
</Autodiscover>

Die Namespaces beginnen mit http://, nicht mit https://. Das ist kein Tippfehler: XML-Namespaces sind reine Bezeichner, keine abrufbaren URLs, und werden Zeichen für Zeichen verglichen. Microsofts Doku zeigt sie stellenweise mit https:// an – ein Artefakt der Doku-Plattform, das die Bezeichner verfälscht. Der Wert in AcceptableResponseSchema muss außerdem exakt dem Namespace der Antwort entsprechen, sonst passt die Anfrage nicht zum ausgelieferten Schema.

Eine mögliche statische Antwort für IMAP und SMTP sieht so aus:

<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
  <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <Account>
      <AccountType>email</AccountType>
      <Action>settings</Action>

      <Protocol>
        <Type>IMAP</Type>
        <Server>mail.example.com</Server>
        <Port>993</Port>
        <SSL>on</SSL>
        <SPA>off</SPA>
        <AuthRequired>on</AuthRequired>
      </Protocol>

      <Protocol>
        <Type>SMTP</Type>
        <Server>mail.example.com</Server>
        <Port>465</Port>
        <SSL>on</SSL>
        <SPA>off</SPA>
        <AuthRequired>on</AuthRequired>
      </Protocol>
    </Account>
  </Response>
</Autodiscover>

Die Namespaces gehören zum Protokoll und müssen unverändert bleiben.

SPA steht für Secure Password Authentication, also Microsofts NTLM-basierte Authentifizierung. Für ein normales IMAP-/SMTP-Konto mit Passwortauthentifizierung muss der Wert ausdrücklich auf off stehen.

LoginName fehlt in diesem Beispiel bewusst. Eine statische Datei kann schließlich nicht für jeden Nutzer einen anderen Wert einsetzen. Das funktioniert nur bei Clients, die ersatzweise die eingegebene Mailadresse als Login verwenden.

Möchtest Du den Login-Namen ausdrücklich zurückgeben, mehrere Domains unterschiedlich behandeln oder abhängig von der Mailadresse verschiedene Server ausliefern, brauchst Du einen dynamischen Endpunkt, der den POST-Body verarbeitet.

XML-Dateien mit nginx ausliefern

Für Thunderbird benötigst Du mindestens einen HTTPS-vHost für autoconfig.example.com oder den entsprechenden .well-known-Pfad auf der Hauptdomain.

Thunderbird Autoconfig

server {
    listen 443 ssl;
    server_name autoconfig.example.com;

    # ssl_certificate     /pfad/zum/fullchain.pem;
    # ssl_certificate_key /pfad/zum/privkey.pem;

    location = /mail/config-v1.1.xml {
        default_type application/xml;
        alias /var/www/autoconfig/config-v1.1.xml;
    }
}

Die .well-known-Variante kommt zusätzlich in den bestehenden HTTPS-vHost von example.com:

location = /.well-known/autoconfig/mail/config-v1.1.xml {
    default_type application/xml;
    alias /var/www/autoconfig/config-v1.1.xml;
}

Beide Pfade dürfen dieselbe Datei ausliefern.

Statisches Autodiscover trotz POST

Ein POST auf eine normale statische Datei beantwortet nginx mit 405 Method Not Allowed. Über error_page lässt sich dieser Fehler intern auf einen GET gegen eine zweite, nicht öffentlich erreichbare Location umleiten:

server {
    listen 443 ssl;
    server_name autodiscover.example.com;

    # ssl_certificate     /pfad/zum/fullchain.pem;
    # ssl_certificate_key /pfad/zum/privkey.pem;

    location = /Autodiscover/Autodiscover.xml {
        default_type text/xml;
        error_page 405 =200 /_autodiscover-static.xml;
        alias /var/www/autodiscover/autodiscover.xml;
    }

    location = /autodiscover/autodiscover.xml {
        default_type text/xml;
        error_page 405 =200 /_autodiscover-static.xml;
        alias /var/www/autodiscover/autodiscover.xml;
    }

    location = /_autodiscover-static.xml {
        internal;
        default_type text/xml;
        alias /var/www/autodiscover/autodiscover.xml;
    }
}

Bei der internen Weiterleitung ändert nginx einen POST in einen GET und liefert anschließend die statische Datei mit Status 200 aus.

Dieses Setup ignoriert den Request-Body vollständig. Es ist deshalb nur dann geeignet, wenn wirklich jeder Nutzer dieselben Server, Ports und Authentifizierungsverfahren verwenden soll.

Sobald die Antwort von der angefragten Mailadresse abhängt, gehört an diese Stelle eine kleine Anwendung statt einer statischen Datei.

Zertifikate für die Web-Endpunkte

Die Hosts müssen gültige HTTPS-Zertifikate besitzen:

autoconfig.example.com
autodiscover.example.com

Ein Wildcard-Zertifikat für *.example.com deckt beide Subdomains ab. Es deckt jedoch nicht automatisch die Hauptdomain example.com selbst ab. Möchtest Du auch die .well-known-URL oder den Autodiscover-Pfad direkt auf der Hauptdomain bereitstellen, muss das Zertifikat zusätzlich example.com enthalten.

Wenn Du nur die DNS-Zone kontrollierst

Liegt das Postfach bei einem externen Provider, kannst Du die SRV-Records trotzdem selbst setzen:

_imaps._tcp.example.com.        SRV 0 0 993 imap.provider.example.
_submissions._tcp.example.com.  SRV 0 0 465 smtp.provider.example.
_submission._tcp.example.com.   SRV 0 0 587 smtp.provider.example.

Verwende dabei ausschließlich die vom Provider dokumentierten Hostnamen und Ports.

Einige Anbieter unterstützen außerdem eigene Autoconfig- oder Autodiscover-Subdomains über CNAME:

autoconfig.example.com.   CNAME autoconfig.provider.example.
autodiscover.example.com. CNAME autodiscover.provider.example.

Das ist für normale Web-Hostnamen erlaubt und nicht mit dem CNAME-Verbot für SRV-Targets zu verwechseln.

Der Provider muss dabei allerdings ein gültiges Zertifikat für Deine angefragte Subdomain präsentieren können. Ein CNAME ändert nicht den Hostnamen, den der Client per HTTPS aufruft und gegen das Zertifikat prüft.

Setze solche Records daher nur, wenn der Provider dieses Verfahren ausdrücklich für Custom Domains dokumentiert.

Konfiguration testen

SRV-Records

dig +short SRV _imaps._tcp.example.com
dig +short SRV _submissions._tcp.example.com
dig +short SRV _submission._tcp.example.com
dig +short SRV _autodiscover._tcp.example.com

Prüfe zusätzlich, ob das Target direkt A- oder AAAA-Records besitzt:

dig +short A mail.example.com
dig +short AAAA mail.example.com

Thunderbird Autoconfig

curl --fail-with-body \
  -D - \
  'https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=alice@example.com'

Damit siehst Du gleichzeitig:

• HTTP-Status
• Zertifikatsfehler
• Redirects
• Content-Type
• ausgelieferte XML-Datei

Die XML-Syntax lässt sich lokal mit xmllint prüfen:

xmllint --noout /var/www/autoconfig/config-v1.1.xml

Autodiscover-POST

Lege zunächst einen beispielhaften Request an:

cat > /tmp/autodiscover-request.xml <<'EOF'
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006">
  <Request>
    <EMailAddress>alice@example.com</EMailAddress>
    <AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema>
  </Request>
</Autodiscover>
EOF

Anschließend sendest Du ihn per POST:

curl --fail-with-body \
  -D - \
  -H 'Content-Type: text/xml; charset=utf-8' \
  --data-binary @/tmp/autodiscover-request.xml \
  https://autodiscover.example.com/Autodiscover/Autodiscover.xml

Der Server sollte mit Status 200 und der Autodiscover-Antwort reagieren.

Microsofts Remote Connectivity Analyzer kann den Autodiscover-Endpunkt zusätzlich aus Sicht eines externen Systems prüfen. Ein erfolgreicher Test bestätigt jedoch nicht zwangsläufig, dass jede Outlook-Version daraus ein generisches IMAP-Konto erstellt.

TLS der Mailserver

Das Zertifikat des IMAP-Servers kannst Du mit OpenSSL kontrollieren:

openssl s_client \
  -connect mail.example.com:993 \
  -servername mail.example.com \
  -verify_return_error </dev/null

Für SMTP Submission mit implizitem TLS:

openssl s_client \
  -connect mail.example.com:465 \
  -servername mail.example.com \
  -verify_return_error </dev/null

Und für Port 587 mit STARTTLS:

openssl s_client \
  -starttls smtp \
  -connect mail.example.com:587 \
  -servername mail.example.com \
  -verify_return_error </dev/null

Typische Stolperfallen

• Client-Unterstützung überschätzen: Ein standardisierter SRV-Record bedeutet nicht, dass jeder Client ihn auch verwendet.
• SRV-Target als CNAME anlegen: Das Target muss selbst über A- oder AAAA-Records erreichbar sein.
• Web-CNAME und SRV-Target verwechseln: Ein CNAME für autoconfig.example.com kann erlaubt sein, ein CNAME als SRV-Ziel nicht.
• Falscher Login-Platzhalter: Manche Server erwarten die vollständige Mailadresse, andere nur den Local Part.
• Port und TLS-Modus vermischen: Port 465 verwendet üblicherweise implizites TLS, Port 587 STARTTLS.
• _submission und _submissions verwechseln: _submission gehört zu Port 587, _submissions zu Port 465.
• Autodiscover nur per GET testen: Outlook sendet normalerweise einen POST mit XML-Body.
• Groß- und Kleinschreibung ignorieren: Unter nginx sind /Autodiscover/Autodiscover.xml und /autodiscover/autodiscover.xml unterschiedliche Pfade.
• Unpassende Zertifikate: Sowohl die Mailserver als auch die Web-Endpunkte benötigen Zertifikate für die tatsächlich verwendeten Hostnamen.
• Ungeplante Redirects: Besonders POST-Requests können bei Redirects ihr Verhalten oder ihre Methode ändern. Der endgültige Autodiscover-Pfad sollte deshalb möglichst direkt mit 200 antworten.
• Caching vergessen: DNS-Resolver und Clients können alte Einstellungen noch bis zum Ablauf der TTL verwenden.

Fazit

Beginne mit den SRV-Records. Sie sind schnell eingerichtet, standardisiert und helfen allen Clients, die RFC 6186 und RFC 8314 unterstützen.

Für Thunderbird ist die eigene config-v1.1.xml jedoch der deutlich zuverlässigere Weg. Sie beschreibt nicht nur Server und Ports, sondern auch TLS-Modus, Authentifizierung und das Format des Benutzernamens.

Microsoft Autodiscover lohnt sich vor allem dann, wenn Outlook ausdrücklich zu Deinen unterstützten Clients gehört. Da sich klassische und aktuelle Outlook-Varianten bei generischen IMAP-Konten unterschiedlich verhalten können, solltest Du diesen Teil nicht nur mit curl, sondern mit den tatsächlich eingesetzten Clients testen.

Eine universelle Garantie gibt es nicht. Mit sauberen SRV-Records, Thunderbird Autoconfig und einem getesteten Autodiscover-Endpunkt reduzierst Du die manuelle Einrichtung aber in vielen Umgebungen tatsächlich auf Mailadresse und Passwort.

Quellen:

• RFC 2782 – A DNS RR for specifying the location of services
• RFC 6186 – Use of SRV Records for Locating Email Submission/Access Services
• RFC 8314 – Cleartext Considered Obsolete
• Mozilla: Thunderbird Autoconfiguration
• Thunderbird: aktuelle Implementierung der Autoconfig-Abfrage
• Microsoft: POX Autodiscover request
• Microsoft: Protocol element in POX Autodiscover
• nginx: error_page