Ports, chiffrement et connexion

Module 1: Comment fonctionne l'e-mail · Temps de lecture : 10 minutes

Objectif pédagogique : Après cette leçon, vous saurez dire à quoi sert chaque port de messagerie, expliquer la différence entre STARTTLS et le TLS direct, et interpréter un message de certificat ou une connexion refusée.

Notions clés : port 25, 587, 465, 993, 995, 143, 110, STARTTLS, TLS direct (implicit TLS, RFC 8314), certificat, nom de serveur, authentification SMTP (SMTP AUTH), relais ouvert (open relay), blocage du port 25, mot de passe d'application, OAuth

Un port est une porte

Un serveur possède une seule adresse IP, mais de nombreuses portes. Chaque service écoute sur son propre port, un numéro. Votre navigateur web frappe au port 443, votre programme de messagerie au port 993 pour lire le courrier et au port 587 ou 465 pour en envoyer. Si vous choisissez la mauvaise porte, personne ne répond, ou quelqu'un qui parle une autre langue. Cela donne des messages d'erreur vagues du type « impossible de se connecter » ou « le serveur ne répond pas ».

Les ports de messagerie en un coup d'œil :

Pourquoi ne pas simplement utiliser le port 25 pour l'envoi ?

Autrefois, vous configuriez le port 25 dans votre programme de messagerie. C'est du passé, pour deux raisons.

Premièrement : sur le port 25, un serveur de messagerie accepte le courrier de tout le monde, pour ses propres domaines. On ne s'y connecte pas. Un serveur qui, sur le port 25, retransmet aussi le courrier de tout le monde vers d'autres domaines s'appelle un relais ouvert (open relay), et il est exploité par des spammeurs en quelques heures. C'est pourquoi l'envoi de votre propre courrier vers le monde entier est devenu un service distinct : la submission sur le port 587 (et 465), où vous vous connectez toujours au préalable.

Deuxièmement : de nombreux fournisseurs d'accès à internet bloquent le trafic sortant vers le port 25 depuis les connexions domestiques. Un ordinateur infecté dans un salon ne peut alors pas envoyer directement du spam vers les serveurs de messagerie. Conséquence pour vous : si vous essayez d'envoyer depuis votre programme de messagerie via le port 25, cela peut ne pas fonctionner chez vous mais fonctionner au bureau, ou l'inverse.

Retenez : les programmes de messagerie envoient via 587 ou 465, avec connexion. Le port 25 est réservé aux échanges entre serveurs.

STARTTLS ou TLS direct ?

Il existe deux manières de chiffrer une connexion de messagerie.

Le TLS direct (implicit TLS) : la connexion est chiffrée dès le premier octet, comme un site web en https. C'est le cas sur les ports 465, 993 et 995.

STARTTLS : la connexion commence en clair. Le serveur dit « je peux chiffrer », le client répond STARTTLS, et à partir de ce moment tout est chiffré. C'est le cas sur le port 587 (et sur 25, 143 et 110).

Pour la sécurité, cela importe peu, tant que votre programme impose STARTTLS de manière obligatoire. Le risque de STARTTLS se situe au début : quelqu'un placé entre vous et le serveur peut effacer l'offre « je peux chiffrer ». Un programme qui, dans ce cas, continue silencieusement sans chiffrement envoie votre mot de passe en clair sur la ligne. C'est pourquoi la RFC 8314 (2018) recommande aux programmes de messagerie le TLS direct (465, 993, 995) plutôt que STARTTLS. En pratique, le port 587 avec STARTTLS et le port 465 avec SSL/TLS sont tous deux corrects, à condition de régler le chiffrement de votre programme sur « obligatoire » et non sur « si disponible ».

Une erreur fréquente est la mauvaise combinaison : le port 587 avec « SSL/TLS », ou le port 465 avec « STARTTLS ». Le programme s'attend alors à autre chose que ce que fait le serveur, et la connexion reste bloquée ou échoue. Retenez les paires : 587 + STARTTLS et 465 + SSL/TLS. Les programmes appellent parfois le TLS direct « SSL », « SSL/TLS » ou « TLS » ; STARTTLS est parfois aussi appelé « TLS ». Regardez donc le port.

Le certificat et le nom du serveur

À chaque connexion chiffrée, le serveur présente un certificat, qui prouve qu'il est bien celui qu'il prétend être. Votre programme de messagerie vérifie deux choses : le certificat a-t-il été délivré par une autorité de confiance et est-il encore valide, et le nom que vous avez indiqué comme serveur y figure-t-il ?

C'est ce dernier point qui pose le plus souvent problème. Si vous indiquez mail.example.com, mais que le certificat ne mentionne que server12.hosting.example, vous obtenez un message du type « Impossible de vérifier l'identité du serveur » ou « Le nom principal de la cible est incorrect ». La connexion elle-même est bien chiffrée, mais votre programme ne peut pas être certain qu'il communique avec le vrai serveur.

Ne fermez pas un tel message sans vérifier. La solution consiste à indiquer un nom de serveur qui figure effectivement dans le certificat (voir leçon 2.1). Sur un serveur mutualisé, il s'agit souvent du nom du serveur lui-même, indiqué par votre prestataire. Autre cause connue : un antivirus qui « analyse » le courrier chiffré et insère pour cela son propre certificat. Dans ce cas, le message indique le nom de l'antivirus à la rubrique « délivré par ».

Connexion lors de l'envoi

Sur les ports 587 et 465, vous devez vous connecter avant que le serveur accepte d'envoyer votre courrier vers l'extérieur. On appelle cela l'authentification SMTP (SMTP AUTH). Dans votre programme, l'option s'appelle « le serveur sortant requiert une authentification », « connexion requise » ou « authentification : mot de passe normal ». En général, vous utilisez le même nom d'utilisateur et le même mot de passe que pour l'IMAP.

Si l'authentification est désactivée, ou si le nom d'utilisateur du serveur sortant est resté vide, vous pouvez lire le courrier mais pas en envoyer. Le serveur répond alors par quelque chose comme 530 5.7.0 Authentication required ou 554 5.7.1 Relay access denied. C'est la cause la plus fréquente du problème « la réception fonctionne, pas l'envoi ».

Un deuxième type de refus : 535 5.7.8 Authentication failed. Dans ce cas, la combinaison nom d'utilisateur/mot de passe est incorrecte. Attention : après un certain nombre de tentatives échouées, de nombreux serveurs bloquent l'adresse IP d'où proviennent ces tentatives, pour se prémunir contre les attaques par force brute. Un ancien téléphone avec un mot de passe obsolète peut ainsi faire bloquer tout votre bureau.

Mots de passe d'application et OAuth

Chez les grands fournisseurs comme Google et Microsoft, la connexion avec simplement votre mot de passe habituel dans un programme de messagerie externe fonctionne de moins en moins souvent. Ils utilisent OAuth : votre programme vous redirige vers une page de connexion du fournisseur, vous vous y connectez (éventuellement avec la validation en deux étapes), et le programme reçoit une clé à la place de votre mot de passe. Les programmes qui ne le permettent pas reçoivent parfois un mot de passe d'application : un mot de passe distinct et long, valable uniquement pour ce programme précis, que vous pouvez révoquer indépendamment.

Pour une boîte mail classique chez un hébergeur, vous vous connectez généralement avec le mot de passe de la boîte mail elle-même. Cela rend un mot de passe fort et unique d'autant plus important (leçon 3.4).

En pratique : les paramètres d'une boîte mail

Pour une boîte mail WebOké, les paramètres sont : IMAP 993 avec SSL/TLS, POP3 995 avec SSL/TLS, envoi via 587 avec STARTTLS ou 465 avec SSL/TLS, authentification activée avec votre adresse e-mail complète et le mot de passe de la boîte mail. Chez d'autres fournisseurs, cela fonctionne de manière comparable : les ports sont presque partout les mêmes, seul le nom du serveur diffère. Pour savoir quel nom de serveur choisir, consultez la leçon 2.1.

Résumé

• Les programmes de messagerie envoient via le port 587 (STARTTLS) ou 465 (TLS direct), toujours avec connexion. Le port 25 est réservé aux échanges entre serveurs et est souvent bloqué à domicile.
• La lecture passe par le port 993 (IMAP) ou 995 (POP3), tous deux avec TLS direct.
• Associez correctement : 587 + STARTTLS, 465 + SSL/TLS. Réglez le chiffrement sur obligatoire.
• Un message de certificat signifie généralement que le nom de serveur que vous avez indiqué ne figure pas dans le certificat. Fermer le message sans agir n'est pas une solution.
• « La lecture fonctionne, pas l'envoi » signifie presque toujours : l'authentification pour le serveur sortant est désactivée ou vide.

Quiz

Exercice

Exercice Z1.4 : Ports et certificat d'un serveur de messagerie. Indiquez le nom du serveur entrant et du serveur sortant que vous utilisez pour votre propre boîte mail (si vous n'en avez pas, utilisez imap.gmail.com et smtp.gmail.com). Pour le port 993 (entrant) et les ports 465 et 587 (sortant), indiquez ce que vous attendez : TLS direct, STARTTLS ou inaccessible, et précisez si vous pensez que le nom figure dans le certificat. Le programme se connecte lui-même aux trois ports et compare le résultat à vos réponses.

Pour aller plus loin

Les étapes décrites dans ces articles s'appliquent aux panneaux de WebOké ; chez d'autres prestataires, le fonctionnement est comparable.

• Guide DirectAdmin 8.1: Tous les paramètres en un coup d'œil : serveurs, ports et sécurité
• Guide DirectAdmin 8.8: Envoyer ou recevoir des e-mails ne fonctionne pas : comment résoudre le problème
• Erreur de certificat lors de la réception des e-mails
• Je ne parviens pas à envoyer d'e-mails (la réception fonctionne)
• RFC 8314 (TLS direct pour les programmes de messagerie), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)