5 idées reçues sur le SMTP qui piègent les expéditeurs d’emails

Le SMTP existe depuis 1982. Après plus de quatre décennies, on pourrait s’attendre à ce que tout soit parfaitement maîtrisé. Et pourtant, certains des problèmes de livraison d’emails les plus persistants proviennent d’une poignée d’idées reçues tenaces à propos de ce que fait réellement le SMTP.

Le protocole n’a qu’une seule mission : transporter les emails entre les serveurs. Et il remplit très bien cette mission. Mais il n’authentifie pas votre identité, ne garantit pas le placement en boîte de réception, ne chiffre pas votre contenu par défaut, et ne gère pas les rebonds de la manière dont la plupart des expéditeurs le supposent. Comprendre où s’arrête le rôle de SMTP et où commencent les autres mécanismes est la clé pour disposer d’une infrastructure email fiable, plutôt que d’un système constamment en difficulté.

Le SMTP, l’acronyme de Simple Mail Transfer Protocol ou protocole simple de transfert de courrier, est un protocole de transport. Il déplace l’email d’un serveur à un autre. C’est tout son travail. Considérez le SMTP comme le livreur qui récupère un colis et le dépose sur le quai de déchargement du bâtiment de votre destinataire. Ce qui se passe ensuite, à savoir si quelqu’un est présent pour le recevoir, si le colis est retenu au contrôle de sécurité, ou s’il atterrit sur le bon bureau, échappe entièrement au contrôle du livreur.
Le SMTP régit l’échange initial entre les serveurs : la salutation EHLO, les commandes MAIL FROM et RCPT TO, le transfert du message et la réponse finale 250 OK venant confirmer l’acceptation. Une fois ce 250 reçu, le SMTP considère son travail terminé. Que le message arrive dans la boîte de réception, le dossier spam ou n’arrive nulle part est une question distincte, et c’est là que se logent la plupart des idées reçues. Si vous souhaitez une explication complète de l’ensemble du processus d’envoi SMTP, nous l’avons détaillé en profondeur.

C’est probablement le malentendu le plus coûteux en matière d’email. Une réponse 250 OK d’un serveur configuré pour recevoir des emails signifie que ce serveur a accepté votre message, non pas qu’il l’a livré dans la boîte de réception. Le serveur configuré pour recevoir des emails est libre de faire ce qu’il veut avec le message après son acceptation : appliquer un filtre pour l’envoyer en spam, le mettre en quarantaine ou l’ignorer silencieusement.

Le SMTP fonctionne au niveau de la couche de transport. Le placement en boîte de réception est une question de délivrabilité, régie par la réputation d’expéditeur, les signaux d’authentification, l’historique d’engagement et les signaux de contenu. Aucun de ces éléments n’est directement traité par le SMTP. Lorsque vous cherchez à débugger de faibles taux d’ouverture ou un placement en spam élevé, ne regardez pas uniquement les rapports SMTP. Examinez votre réputation d’expéditeur, votre configuration d’authentification et la santé de votre liste. Notre guide sur les mythes courants concernant la délivrabilité des emails est un bon point de départ pour démêler les deux.

Le SMTP a été conçu à une époque où la confiance était bien plus forte. Le protocole d’origine ne prévoit aucun mécanisme pour vérifier que l’expéditeur est bien celui qu’il prétend être : il se contente de considérer l’adresse MAIL FROM comme valide. C’est pourquoi l’usurpation d’email est un problème depuis des décennies.

L’authentification est ajoutée au-dessus du SMTP, elle n’y est pas intégrée. SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) et DMARC (Domain-based Message Authentication, Reporting, and Conformance) fonctionnent tous indépendamment de l’échange initial SMTP entre serveurs. SMTP AUTH, le mécanisme qui exige un nom d’utilisateur et un mot de passe avant que votre client de messagerie ne transmette un message, est également un module complémentaire distinct, défini dans la RFC 4954, et non dans la spécification SMTP de base.
Ce que cela signifie en pratique : un 250 OK provenant d’un serveur configuré pour recevoir des emails ne vient pas confirmer que vos enregistrements d’authentification sont en règle. Vous pouvez transmettre un message avec succès via SMTP et malgré tout le voir classé en spam ou rejeté si votre enregistrement SPF est incorrect ou si votre signature DKIM ne peut pas être vérifiée. Corrigez l’authentification en premier, le SMTP ne le fera pas à votre place. Notre guide sur l’authentification des emails détaille la configuration du protocole SPF, de DKIM et de DMARC de A à Z.

Par défaut, le SMTP classique va envoyer tout le contenu en texte clair. En-têtes d’email, contenu des messages, identifiants, tout cela est potentiellement visible par quiconque surveille la connexion. Ce n’était pas une préoccupation majeure aux débuts d’internet ; c’est un problème sérieux aujourd’hui.
Le chiffrement est apparu plus tard, sous forme de couche séparée. Deux options couvrent la plupart des scénarios d’envois :

STARTTLS
STARTTLS est une extension de protocole qui permet à un client de mettre à niveau une connexion SMTP en texte clair existante vers une connexion chiffrée. Il est pris en charge sur les ports 25 et 587. Le mot-clé est « mise à niveau », si le serveur de réception ne prend pas en charge STARTTLS, la connexion peut se replier sur du texte clair. C’est ce que l’on appelle parfois le TLS opportuniste, et c’est l’approche dominante pour le relais de serveur à serveur.

SMTPS (TLS implicite)
SMTPS ouvre une connexion chiffrée par TLS dès le départ, sans phase en texte clair. Il fonctionne sur le port 465 (pour la soumission client-serveur) et constitue l’option la plus sécurisée lorsque les deux parties le prennent en charge. Ce qu’il faut retenir en pratique : veillez toujours à configurer vos envois pour qu’ils utilisent TLS, et à confirmer que votre service d’emailing l’impose. Notre analyse détaillée des ports SMTP couvre les implications de sécurité de chaque choix de port. Ne partez pas du principe que parce que votre message a été accepté, la connexion était chiffrée.

Le port 25 est le port SMTP d’origine, datant de 1982. C’est aussi le port le plus susceptible de vous attirer des ennuis.
La plupart des FAI et des fournisseurs d’hébergement bloquent le port 25 sortant sur les réseaux non-serveurs, précisément parce qu’il est massivement exploité par les spammeurs. Si vous créez une application qui gère des envois d’email et que vous effectuez le routage via le port 25, vous rencontrerez des erreurs de connexion sur de nombreux réseaux et vos messages ne partiront pas.
Les ports à connaître :

Port 587 : Le standard moderne pour la soumission d’email authentifiée (SMTP avec STARTTLS). Utilisez-le pour la soumission client-serveur dans presque tous les cas.
Port 465 : Déprécié pendant un certain temps, mais désormais largement utilisé pour SMTPS (TLS implicite). De nombreux services d’emailing, dont Mailgun, le prennent en charge.
Port 2525 : Une solution de repli pratique en cas de blocage du 587. Mailgun le prend en charge.
Port 25 : Uniquement pour le relais de serveur à serveur. Non destiné à la soumission client. Fait souvent l’objet d’un blocage.

Pour un historique complet et une recommandation claire pour votre configuration, consultez notre guide sur les ports SMTP.

Ce mythe a tendance à faire surface lorsque les équipes veulent réduire les coûts de leur service d’emailing ou conserver l’infrastructure d’email en interne. La logique semble raisonnable à première vue : à quel point un serveur SMTP peut-il être complexe à gérer ?

En pratique, maintenir votre propre infrastructure SMTP est l’un des moyens les plus rapides de dégrader votre délivrabilité sans comprendre pourquoi. Gérer votre propre serveur signifie que vous êtes responsable de tout ce que le SMTP ne gère pas : la préchauffe des IP, le traitement des rebonds et des plaintes, la gestion de la liste de suppression, l’inscription aux boucles de rétroaction avec les principaux fournisseurs de messagerie, la maintenance des certificats TLS, la surveillance des listes de blocage, et le maintien de la conformité avec les exigences évolutives des expéditeurs chez Gmail, Yahoo et Microsoft. C’est un travail à temps plein et c’est précisément le type de tâche sur lequel les ESP ont passé des années à développer des outils spécialisés.

Au-delà de la surcharge opérationnelle, les serveurs autogérés se trouvent souvent sur des blocs d’IP partagée avec de mauvaises réputations, et les nouvelles adresses IP sont confrontées à d’importants obstacles au placement en boîte de réception jusqu’à ce qu’une période de préchauffe établisse un historique des envois.

Pour la plupart des équipes, le relais SMTP gère la complexité de l’infrastructure et vous fournit des journaux, des statistiques et des outils de délivrabilité que vous devriez sinon développer vous-même. Et si vous vous demandez s’il faut rester sur le SMTP ou passer à une intégration API, notre comparaison entre SMTP et API expose clairement les compromis.

Le SMTP n’est pas l’ennemi. C’est un protocole remarquablement durable qui route l’email depuis plus de 40 ans, et comprendre ce qu’il fait réellement est la première étape pour construire une configuration des envois propre.

La version courte : le SMTP déplace votre message du point A au point B. Tout le reste, à savoir, le placement en boîte de réception, l’authentification, le chiffrement, la gestion des rebonds, relève de votre responsabilité à configurer en complément. La bonne nouvelle est que l’infrastructure d’email moderne, des protocoles d’authentification aux services de relais gérés, rend cette superposition simple si vous savez par où commencer.

Si vous cherchez à résoudre un échec d’envoi spécifique, notre guide sur les codes d’erreur SMTP vous aidera à décoder exactement ce que le serveur de réception vous dit et comment le corriger.

Author: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!