Auto-configuration des clients mails

Pour que les clients mails (MUA) puissent accéder aux serveurs, ils doivent être configurés correctement.
Il existe plusieurs méthodes d’auto-configuration:

• Enregistrement SRV (RFC 6186)
• autoconfig de Thunderbird
• Autodiscover de Microsoft
• Détection par convention

Cette page fait un point rapide sur chacune d’entre elles.

RFC 6186 - champs DNS SRV

Utilisation des champs DNS SRV pour localiser les serveurs.
Cette méthode permet de spécifier l’adresse et le port de chaque serveur. Elle permet de lister plusieurs serveurs, en load-balancing et en backup.
Elle ne permet pas d’indiquer des paramètres plus complexes, comme le format du nom d’utilisateur si celui-ci n’est pas standard.

Fonctionnement des enregistrements SRV

Un enregistrement SRV sert à indiquer la présence d’un service associé au domaine, et donne les informations pour s’y connecter.

Format d’un champ SRV:

# _service._proto.  SRV    priorité poids port target.

# Example: SIP service géré par un serveur dédié sur le port 5060
_sip._tcp.          SRV    0 33 5060 serveursip1.example.com.

• Priorité: la plus petite valeur est prioritaire.
• Poids: permet de faire du load-balancing.

→ Wikipedia - Enregistrement SRV

Les enregistrements SRV possible sont:

• _submission: serveur SMTP (non chiffré, chiffré avec STARTTLS, et/ou chiffré TLS implicite).
• _submissions: serveur SMTP avec TLS implicite (ajouté dans le RFC 8314, moins utilisé en pratique)
• _imap: serveur IMAP, acceptant les connexions non chiffrées et/ou chiffrées avec STARTTLS.
• _imaps: serveur IMAP avec chiffrement TLS implicite.
• _pop3: serveur POP3, acceptant les connexions non chiffrées et/ou chiffrées avec STLS.
• _pop3s: serveur POP3 avec chiffrement TLS implicite.

La priorité des enregistrements _imap, imaps, _pop3 et _pop3s est commune. On peut donc spécifier quel protocole est prioritaire.

Il est possible d’indiquer qu’un service n’est pas disponible, en indiquant le port 0 et la cible ".". En pratique, OVH ne nous laisse pas la possibilité de rentrer un tel enregistrement SRV, et je ne sais pas à quel point c’est répandu.

Exemple: ici, les protocoles POP3 et IMAP non chiffrés ne sont pas disponibles. Le serveur SMTP utilise le port 465.

_submission._tcp     SRV 0 1 465 mail.example.com.
_submissions._tcp    SRV 0 1 465 mail.example.com.
_imap._tcp           SRV 0 1 0 .
_imaps._tcp          SRV 0 1 993 imap.example.com.
_pop3._tcp           SRV 0 1 0 .
_pop3s._tcp          SRV 0 1 995 pop3.example.com.

NOTE: pour des raisons de sécurité, il est fortement recommandé d’activer DNSSEC.

NOTE: la RFC 7817 spécifie que les certificats TLS des serveurs devraient contenir les champs “SRV-ID” correspondants. En pratique, je ne suis pas sûr que ce soit utilisé.

Liens utiles:

• Bortzmeyer - analyse de la RFC 6186
• RFC 6186

Autoconfig (Thunderbird)

Ce protocole a été créé par Thunderbird, mais est implémenté par beaucoup de projets open-source. Il offre plus de possibilités que les SRV.

Le client mail va chercher un fichier de configuration à partir d’un URL http. Pour alice@example.com, ces 2 adresses sont vérifiées (dans l’ordre):

1. https://autoconfig.example.com/mail/config-v1.1.xml?emailaddress=alice@example.com
2. https://example.com/.well-known/autoconfig/mail/config-v1.1.xml?emailaddress=alice@example.com

Note: Certains clients mails comme Evolution envoient une fausse valeur dans le paramètre emailaddress.

Le fichier est très basique. Il comprend une section par méthode de connexion, la 1ère section valide est présélectionnée.

<clientConfig version="1.1">
    <emailProvider id="club-estime.fr">
        <domain>example.fr</domain>
        <displayName>Example Mail Service</displayName>
        <displayShortName>Example</displayShortName>
        <incomingServer type="imap">
            <hostname>imap.example.fr</hostname>
            <port>143</port>
            <socketType>STARTTLS</socketType>
            <authentication>password-cleartext</authentication>
            <username>%EMAILLOCALPART%</username>
        </incomingServer>
        <incomingServer type="pop3">
            <hostname>pop.example.fr</hostname>
            <port>110</port>
            <socketType>STARTTLS</socketType>
            <authentication>password-cleartext</authentication>
            <username>%EMAILLOCALPART%</username>
        </incomingServer>
        <outgoingServer type="smtp">
            <hostname>smtpauth.example.fr</hostname>
            <port>587</port>
            <socketType>STARTTLS</socketType>
            <authentication>password-cleartext</authentication>
            <username>%EMAILLOCALPART%</username>
        </outgoingServer>
    </emailProvider>
</clientConfig>

Aparté: l’intérêt de la balise <username>

Le serveur SMTP de soumission demande un nom d’utilisateur et un mot de passe pour l’authentification. Habituellement, le nom d’utilisateur correspond à l’adresse email, mais pas toujours. Pour un email john.doe@example.com, un client mail va tester john.doe@example.com, puis john.doe. Mais le fournisseur d’email pourrait utiliser autre chose, par exemple john.doe.example.com.

Lien utile:

• Wiki Thunderbird: Format de fichier

Autodiscover (Microsoft)

NDLR: Je n’ai pas mis en place cette solution moi-même. Informations à utiliser avec prudence.

À partir de Outlook 2007, Microsoft utilise le protocole Autodiscover.

Le client mail va chercher un fichier de config en faisant une requête HTTP POST sur les URL suivantes (dans l’ordre):

1. https://example.com/autodiscover/autodiscover.xml
2. https://autodiscover.example.com/autodiscover/autodiscover.xml
3. Le domaine pointé par l’enregistrement SRV _autodiscover._tcp.example.com.

Note: dans le cas d’une redirection HTTP ou d’utilisation de l’enregistrement SRV, le client mail peut afficher une fenêtre de confirmation à l’utilisateur. (à confirmer ?)

Il est possible de servir un fichier statique, la requête POST servant à personnaliser la réponse en fonction de l’adresse email.
Le fichier est très basique: il comprend une section par méthode de connexion, la 1ère section valide est prioritaire.

Exemple de SRV pour autodiscover:

_autodiscover._tcp.example.com.  0   443 service.example-provider.com.

Example de fichier xml:

<?xml version="1.0" encoding="utf-8" ?>
<Autodiscover xmlns="https://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
    <Response xmlns="https://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
    <Account>
        <AccountType>email</AccountType>
        <Action>settings</Action>
        <Protocol>
            <Type>IMAP</Type>
            <Server>mail.contoso.com</Server>
            <Port>993</Port>
            <DomainRequired>off</DomainRequired>
            <SPA>off</SPA>
            <SSL>on</SSL>
            <AuthRequired>on</AuthRequired>
        </Protocol>
        <Protocol>
            <Type>POP3</Type>
            <Server>mail.contoso.com</Server>
            <Port>995</Port>
            <DomainRequired>off</DomainRequired>
            <SPA>off</SPA>
            <SSL>on</SSL>
            <AuthRequired>on</AuthRequired>
            <UsePOPAuth>on</UsePOPAuth>
        </Protocol>
        <Protocol>
            <Type>SMTP</Type>
            <Server>mail.contoso.com</Server>
            <Port>587</Port>
            <DomainRequired>off</DomainRequired>
            <SPA>off</SPA>
            <SSL>on</SSL>
            <AuthRequired>on</AuthRequired>
            <UsePOPAuth>on</UsePOPAuth>
            <SMTPLast>on</SMTPLast>
        </Protocol>
    </Account>
    </Response>
</Autodiscover>

Liens utiles:

• Microsoft - White Paper: Understanding the Exchange 2010 Autodiscover Service - Le guide de Microsoft le plus complet sur le sujet.
• Microsoft - Plan to automatically configure user accounts in Outlook 2010 - Autre doc, plus succincte.
• How to quickly verify is Autodiscover is working

Par convention

Pour les clients qui ne supportent pas les méthodes ci-dessus, ils essayent des noms de serveurs possible à partir du domaine principal.
S’assurer que les noms de domaine suivants existent et pointent vers les bons serveurs (CNAME ou A et AAAA).

• smtp.example.com
• imap.example.com
• pop3.example.com
• mail.example.com (utilisé à la fois pour les serveurs IMAP et SMTP)

J’ai aussi vu imp.example.com, mais ce dernier est beaucoup moins utilisé.

NOTE: Pour faire les choses bien, tous les noms de domaine utilisés ici devraient être utilisés dans les certificats TLS des serveurs correspondants, même si on utilise des CNAME. En pratique, les clients mails n’utilisant pas les protocoles au-dessus sont aussi les clients mails qui ne vérifient pas les certificats TLS.

Liens & projets relatifs

On trouve plein d’implémentation sur Internet. En vrac, trouvé pendant mes recherches:

• automx2: un serveur pour gérer tout ces protocoles
• role Ansible pour générer les services d’auto-détection
• isp-mailConfig: plugin pour ISPConfig

Note: Il existe aussi les fichiers .mobileconfig, qui semblent être utilisés par iOS. Je ne connais pas assez l’écosystème Apple pour savoir si c’est utilisé et comment.