SMTP, IMAP ou POP3 : quelle différence ?

Quelles sont les exigences ?

SMTP soumet et relaie les messages

SMTP est un protocole « push ». Un client ou serveur d’envoi ouvre une connexion, s’identifie, fournit l’expéditeur et le destinataire d’enveloppe, puis transfère les données. SMTP ne permet ni de parcourir une boîte ni de synchroniser l’état lu.

EHLO mailclient.yourdomain.com
MAIL FROM:<sender@yourdomain.com>
RCPT TO:<recipient@example.net>
DATA
From: sender@yourdomain.com
To: recipient@example.net
Subject: Illustrative SMTP message
Example message content.
.
QUIT

Exemple seulement. N’utilisez pas un serveur de production sans ses réglages d’authentification et de TLS.

Pour la soumission par l’utilisateur, la RFC 6409 attribue le port 587 et dit qu’un serveur de soumission DOIT prendre en charge STARTTLS. Il peut exiger l’authentification selon sa politique locale. Le port 25 reste le port de relais SMTP pour le transfert, mais ce n’est pas le choix normal pour un client.

IMAP accède à une boîte serveur

IMAP permet à un client d’accéder aux messages et à l’état de boîte gardés par le serveur. La RFC 9051 définit la sélection de boîtes, la récupération, la recherche et le changement d’indicateurs. Grâce à cet état côté serveur, plusieurs clients IMAP voient les mêmes dossiers et indicateurs en se synchronisant avec la même boîte.

a001 LOGIN user@example.com password
a002 SELECT INBOX
a003 FETCH 1:* (FLAGS)
a004 LOGOUT

Exemple seulement. Ne mettez pas de vrais mots de passe dans un historique de terminal, un ticket ou une doc.

IMAP ne garantit pas un cache local identique dans chaque client à chaque instant. Un client peut travailler hors ligne sur des données en cache, puis se réconcilier avec le serveur. La distinction utile : la boîte et son état restent accessibles aux clients via le serveur.

POP3 relève les messages pour un client

POP3 est un protocole d’accès au modèle plus simple. La RFC 1939 décrit les états d’autorisation, de transaction et de mise à jour. Un client liste et récupère en général les messages, puis peut les marquer pour suppression avant de fermer la session.

USER user@example.com
PASS password
STAT
LIST
RETR 1
QUIT

Exemple seulement. N’utilisez pas de vrais identifiants dans un script de test ou un journal partagé.

POP3 ne définit ni dossiers serveur à la IMAP, ni indicateurs, ni état lu synchronisé. Un client peut laisser les messages sur le serveur, mais c’est un choix de configuration client et serveur, pas l’équivalent d’une synchronisation IMAP. Pour des dossiers et un statut lu cohérents entre portables, téléphones et webmail, IMAP convient en général mieux.

TLS protège la connexion du protocole

La RFC 8314 recommande un accès au courrier sans texte en clair. Elle met à jour les ports enregistrés du TLS implicite : 465 pour la soumission, 993 pour IMAP et 995 pour POP3. Elle décrit aussi STARTTLS comme mécanisme de mise à niveau des ports en clair.

Utilisez les réglages publiés par le fournisseur de boîte ou de soumission. L’enregistrement RFC ne prouve pas qu’un fournisseur gère chaque port ou méthode d’authentification. Il peut exiger une version TLS approuvée, un nom d’hôte précis, une authentification OAuth ou un autre réglage local.

Ne passez pas un client qui fonctionne d’IMAP à POP3 sans vérifier la rétention et la sauvegarde. Un client POP3 peut supprimer les messages du serveur après récupération, ce qui les rend indisponibles pour les autres clients.

Quand l’exigence entre-t-elle en vigueur ?

SMTP, IMAP et POP3 n’ont pas de date de déploiement unique. Chacun est une spécification IETF établie, utilisée par les services qui choisissent de la gérer.

La spécification SMTP de référence est la RFC 5321, publiée en octobre 2008. La RFC 6409, publiée en novembre 2011, définit la soumission et met à jour la RFC 4409. IMAP4rev2 est défini par la RFC 9051, publiée en août 2021, qui rend obsolète la RFC 3501. POP3 reste défini par la RFC 1939, publiée en mai 1996. La RFC 8314, publiée en janvier 2018, met à jour les ports TLS enregistrés pour l’accès et la soumission.

Un fournisseur peut changer ses réglages client indépendamment de ces dates. Consultez sa documentation actuelle avant de changer noms d’hôte, ports, modes TLS ou méthodes d’authentification.

Comment mettre en œuvre l’exigence ?

1. Identifiez les rôles d’envoi et de réception du compte

Notez le nom d’hôte de soumission sortante et celui de la boîte entrante fournis par le fournisseur. Ne supposez pas que c’est le même hôte.

Utilisez SMTP pour le sortant. Choisissez IMAP ou POP3 pour l’entrant seulement. Un compte peut utiliser SMTP plus IMAP, ou SMTP plus POP3.

2. Choisissez IMAP ou POP3 selon l’usage de la boîte

Choisissez IMAP pour un état de boîte partagé entre appareils, des dossiers côté serveur ou un accès par webmail et clients natifs.

Choisissez POP3 seulement si le fournisseur le gère et que l’objectif est un accès par téléchargement. Décidez clairement si le client laisse les messages sur le serveur. Testez ce choix d’abord sur une boîte hors production.

3. Configurez TLS et l’authentification du fournisseur

Utilisez le nom d’hôte, le port, le mode TLS et l’authentification documentés par le fournisseur. La RFC 8314 enregistre 465 pour la soumission, 993 pour IMAP sur TLS et 995 pour POP3 sur TLS.

Ne désactivez pas la validation des certificats pour contourner une erreur de nom d’hôte ou de confiance. Corrigez le nom de serveur configuré ou réglez le problème de certificat via le support du fournisseur.

4. Séparez accès à la boîte et authentification du domaine

Les réglages de transport SMTP ne prouvent pas que le courrier d’un domaine s’authentifie. L’authentification dépend des enregistrements DNS, de la signature, de l’alignement et de l’évaluation du destinataire.

Pour le contexte DNS, voyez en quoi un CNAME diffère d’un enregistrement A et un enregistrement A d’un AAAA. Ces enregistrements peuvent servir la configuration du service, mais ne remplacent ni un enregistrement MX ni un enregistrement d’authentification.

Comment valider la conformité ?

Validez le service configuré à quatre niveaux distincts.

• DNS : résolvez le nom d’hôte du fournisseur depuis le réseau visé et vérifiez l’adresse renvoyée. Cela prouve une résolution publique actuelle, pas que le service accepte les identifiants du compte.
• Fournisseur : vérifiez sa documentation actuelle des réglages client et toute page d’état du compte. Cela confirme le chemin documenté, pas qu’un message a été livré.
• Message : envoyez un test par le chemin exact de soumission SMTP de production. Examinez la boîte de réception et ses en-têtes bruts pour confirmer que le message a pris la route prévue.
• DMARC : une fois les rapports agrégés accumulés, examinez les résultats d’authentification et d’alignement du domaine d’envoi. Vous voyez si les sources de production passent DMARC, ce que la connectivité SMTP seule ne peut établir.

Un score de sécurité e-mail public peut inspecter la posture d’authentification publiée d’un domaine. Il ne peut pas tester vos identifiants, prouver qu’une soumission SMTP a réussi, inspecter l’état privé d’une boîte ni montrer la décision privée d’un destinataire. Pour distinguer un contrôle ponctuel d’une observation continue, voir surveillance active ou passive.

Vérifiez l’authentification du domaine derrière SMTP

SMTP peut soumettre un message, mais une connexion réussie ne montre pas quels services de production passent SPF, DKIM et l’alignement DMARC pour le domaine d’envoi.

Commencez avec Palisade

Palisade, logiciel DMARC agentique, étudie les rapports agrégés, repère les sources d’envoi et les problèmes d’authentification ou d’alignement, et soumet l’étape de politique suivante à un humain. Il ne touche pas aux réglages de protocole du client, ne change pas de lui-même la politique DMARC et ne garantit ni livraison ni placement en boîte de réception.