terme · port smtp

Quel port SMTP une application doit-elle utiliser pour l’e-mail ?

La plupart des applications devraient utiliser l’endpoint de soumission et le port documentés par leur fournisseur d’e-mail. Le port 587 est le port standard de soumission de messages et commence généralement en SMTP en clair avant une mise à niveau STARTTLS. Le port 465 sert à la soumission de messages avec TLS implicite : la négociation TLS commence donc immédiatement. Le port 25 est principalement destiné au relais SMTP de serveur à serveur, et non à la soumission authentifiée habituelle par une application. Une configuration fonctionnelle exige que ces quatre éléments soient cohérents : le nom d’hôte, le port, le mode TLS et la méthode d’authentification.

Un port SMTP détermine un rôle de protocole et un mode de connexion

Un numéro de port n’est pas une simple porte interchangeable vers le même service. Il aide à identifier le rôle SMTP proposé par le serveur et la façon dont la connexion commence. La soumission de messages est la première remise d’une application ou d’un agent utilisateur à un service de soumission. Le relais est le transfert du courrier entre serveurs de messagerie. Les normes séparent ces tâches, car la soumission peut exiger une authentification, une autorisation de l’expéditeur et des contrôles de politique des messages qui ne s’appliquent pas de la même façon au relais public. Le port peut aussi indiquer si le client commence par des commandes SMTP puis passe en TLS avec STARTTLS, ou s’il commence immédiatement par une négociation TLS. Considérez le nom d’hôte, le port, le mode TLS et les instructions d’authentification du fournisseur comme un seul ensemble de configuration. Copier le port d’un fournisseur sans rapport, ou ne changer que le port après une erreur, peut transformer un problème réseau en échec TLS ou d’authentification sans corriger la cause d’origine.

Le port 25 sert principalement au relais entre serveurs de messagerie

Le port 25 est le port de relais SMTP conventionnel, utilisé lorsqu’un Message Transfer Agent remet du courrier à un autre. La RFC 6409 maintient le relais sur le port 25 tout en déplaçant la soumission de nouveaux messages vers le port 587. Une application ne doit donc pas supposer que les connexions directes aux serveurs de messagerie des destinataires sur le port 25 sont la façon normale d’envoyer des e-mails produit. Le relais direct exige une file d’attente, le routage DNS, la gestion des bounces, des contrôles anti-abus, la gestion de la réputation et des nouvelles tentatives conformes aux normes. Les réseaux et les hébergeurs peuvent aussi restreindre le port 25 sortant. AWS, par exemple, documente une limitation par défaut du trafic e-mail d’Amazon EC2 sur le port 25. Le port 25 peut rester une option documentée chez un fournisseur ou au sein d’une infrastructure maîtrisée, mais sa disponibilité n’en fait pas le choix privilégié pour la soumission. Ne l’utilisez que lorsque le service responsable documente explicitement cet endpoint, son mode de sécurité et son modèle opérationnel.

Le port 587 est le port standard de soumission de messages

La RFC 6409 réserve le port 587 à la soumission de messages et décrit un service de soumission qui peut rejeter le courrier non autorisé, exiger une authentification et appliquer une politique avant d’accepter un nouveau message. Une session typique sur le port 587 commence en SMTP, annonce l’extension STARTTLS après `EHLO`, passe la connexion en TLS, répète `EHLO`, s’authentifie puis soumet le message. Le mot typique compte : les mécanismes et exigences d’authentification exacts proviennent de la documentation actuelle du fournisseur et des capacités du serveur. Un client sûr doit exiger la mise à niveau TLS attendue et valider le certificat du serveur, au lieu de continuer en clair après un échec de négociation. Ne confondez pas une salutation initiale non chiffrée avec une session authentifiée non protégée : STARTTLS est conçu pour sécuriser cette connexion avant l’envoi des identifiants et des données du message. Le port 587 identifie le service de soumission, tandis que l’application effective de TLS dépend d’une politique client correcte.

Le port 465 utilise le TLS implicite pour la soumission

Le port 465 est enregistré pour la soumission de messages en TLS implicite. Avec le TLS implicite, le client effectue la négociation TLS dès l’ouverture de la connexion TCP et n’envoie de commandes SMTP qu’à l’intérieur du canal protégé. C’est différent du port 587 avec STARTTLS, où le client reçoit d’abord une salutation SMTP puis demande la mise à niveau. La RFC 8314 recommande le TLS implicite pour la soumission, tout en décrivant une transition pendant laquelle fournisseurs et clients peuvent prendre en charge à la fois le port 465 en TLS implicite et le port 587 avec STARTTLS. La RFC note que des clients et serveurs correctement implémentés peuvent offrir une sécurité sensiblement équivalente avec l’un ou l’autre mode lorsque TLS est obligatoire. En pratique, il ne faut donc pas déclarer un port universellement correct. Utilisez l’endpoint et le mode exacts pris en charge par le fournisseur. Configurer STARTTLS face à un listener en TLS implicite, ou le TLS implicite face à un listener STARTTLS, échoue généralement avant l’authentification.

Les ports alternatifs propres à un fournisseur sont des contrats explicites

Certains fournisseurs proposent des ports alternatifs pour contourner des restrictions réseau, mais ces numéros ne sont pas des standards SMTP universels valables pour tous les services. Amazon SES documente actuellement STARTTLS sur les ports 25, 587 et 2587, et TLS Wrapper, son terme pour le TLS implicite, sur les ports 465 et 2465. SES exige des connexions chiffrées et publie des endpoints SMTP propres à chaque région. Cela montre pourquoi un port doit être tiré de la documentation du fournisseur choisi plutôt que d’une liste générique. Le port 2587 ne signifie pas STARTTLS partout, et le port 2465 n’identifie pas un service en TLS implicite sur n’importe quel hôte. Les ports alternatifs ne contournent pas non plus la vérification de l’expéditeur, la portée des identifiants, les quotas ou la politique du fournisseur. Consignez l’URL source et la date de vérification avec la configuration de production, pour qu’un opérateur puisse distinguer un paramètre fournisseur intentionnel d’un nombre magique inexpliqué copié dans une variable d’environnement des années plus tôt.

Configurez ensemble le nom d’hôte, le port, TLS et l’authentification

Une configuration SMTP robuste forme un tout : le nom d’hôte du fournisseur, le port, le mode de sécurité du transport, la politique de validation des certificats, le mécanisme d’authentification, le nom d’utilisateur, le secret, le timeout de connexion et l’identité d’envoi. Le nom d’hôte compte, car le certificat TLS est validé par rapport à lui et parce que les fournisseurs peuvent exposer des endpoints régionaux différents. Le port et le mode TLS doivent concorder. L’authentification ne doit avoir lieu qu’une fois le canal protégé prévu établi, et les secrets doivent rester dans un gestionnaire de secrets plutôt que dans le code source, les bundles navigateur, les logs ou les sorties de diagnostic. Séparez identifiants et configuration par environnement pour qu’un test local ne puisse pas envoyer par erreur via la production. Fixez des timeouts finis pour la connexion et les commandes, mais laissez une file d’attente applicative durable gérer les nouvelles tentatives des messages. Une option de bibliothèque nommée `secure` peut signifier TLS implicite dans un SDK et simplement exiger STARTTLS dans un autre : vérifiez donc la définition de la bibliothèque et testez le comportement négocié plutôt que de vous fier au nom de l’option.

Testez la connexion par couches sans exposer de secrets

Commencez par la résolution DNS et l’accessibilité TCP depuis le même réseau d’exécution que l’application. Un timeout avant la connexion oriente vers le routage, un pare-feu, la politique de sortie du fournisseur d’hébergement, un mauvais nom d’hôte ou un port fermé. Testez ensuite le mode TLS attendu. En TLS implicite, un client TLS doit recevoir un certificat puis une salutation SMTP. Avec STARTTLS, un client compatible SMTP doit recevoir la salutation, envoyer `EHLO`, voir STARTTLS annoncé, demander la mise à niveau, valider le certificat et renvoyer `EHLO` après TLS. La RFC 3207 exige que le client et le serveur oublient les informations obtenues avant la négociation, d’où l’importance du second `EHLO`. Testez ensuite seulement l’authentification avec un compte contrôlé. Masquez les noms d’utilisateur, jetons, adresses des destinataires, transcriptions complètes du serveur et le contenu des messages avant de partager des logs. Une sonde de connectivité ne nécessite ni envoi en production ni vraie adresse client.

Classez les échecs selon l’étape qui a réellement échoué

Une connexion refusée signifie que la destination TCP a activement décliné la connexion ; un timeout signifie qu’aucune réponse exploitable n’est arrivée dans le délai imparti. Une erreur de négociation TLS indique un mode non concordant, un problème de certificat, une incompatibilité de protocole, une interception ou un mauvais endpoint. Une erreur d’authentification survient plus tard et doit être examinée comme un problème de configuration des identifiants, du mécanisme, du compte ou de l’autorisation, et non corrigée par des changements de port au hasard. Les codes de réponse SMTP pendant `MAIL FROM`, `RCPT TO` ou `DATA` décrivent des décisions encore ultérieures, de politique et de message. Conservez l’étape, l’horodatage, l’endpoint, le nombre de tentatives, la réponse numérique et une réponse filtrée pour la vie privée. Une réponse SMTP 4xx est normalement transitoire et une réponse 5xx normalement définitive pour la commande tentée, mais les nouvelles tentatives doivent être bornées et tenir compte des destinataires. Si le fournisseur a accepté les données du message, ne soumettez pas un doublon à l’aveugle parce qu’une requête applicative ultérieure a expiré ; rapprochez les résultats à l’aide de l’identifiant du fournisseur et de l’historique des événements.

Un port qui répond ne signifie ni livraison du message ni arrivée en boîte de réception

Une connexion TCP réussie prouve seulement qu’un listener a répondu. Une négociation TLS réussie prouve une connexion protégée vers l’endpoint authentifié lorsque la validation du certificat réussit. L’authentification prouve que le serveur a accepté l’identité client présentée pour cette session. Une réponse SMTP `250` après les données du message signifie que le serveur qui répond a accepté la prise en charge selon le protocole, et non qu’une personne a reçu ou lu le message. Un relais ultérieur peut encore échouer, et un système destinataire peut accepter du courrier tout en le classant hors de la boîte de réception principale. Gardez ces états séparés dans les enregistrements applicatifs et la surveillance. La disponibilité réseau, la négociation TLS, l’authentification, l’acceptation par le fournisseur, l’acceptation par le serveur de destination, le bounce, la plainte et l’engagement sont des observations différentes. Cette séparation évite qu’une sonde de port soit présentée à tort comme un test de livraison, et qu’un message accepté soit réessayé simplement parce que l’arrivée en boîte de réception ne peut pas être prouvée.

Choisissez délibérément entre soumission SMTP et API e-mail

Utilisez la soumission SMTP lorsqu’un système dispose déjà d’un client SMTP mature, lorsqu’une plateforme requise expose SMTP comme intégration prise en charge ou lorsque des contrôles au niveau du protocole sont spécifiquement nécessaires. Une API e-mail HTTPS peut constituer une meilleure limite applicative lorsque les requêtes structurées, les jetons à portée limitée, l’idempotence, les ressources par lot et les enregistrements d’événements lisibles par machine correspondent à la charge de travail. Le fournisseur peut toujours utiliser SMTP en aval pour atteindre les systèmes de messagerie des destinataires ; une API n’abolit donc pas le transport de courrier. Elle retire de la configuration SMTP de l’application la responsabilité du port, de TLS, de l’authentification et des nouvelles tentatives lors du transfert vers le fournisseur.

Questions fréquentes

Mon application doit-elle utiliser le port SMTP 587 ou 465 ?

Utilisez le port et le mode TLS documentés par votre fournisseur. Le port 587 utilise normalement STARTTLS, tandis que le port 465 utilise le TLS implicite. Les deux peuvent protéger la soumission lorsqu’ils sont correctement implémentés et exigés ; la configuration du client doit correspondre au listener du serveur.

Pourquoi le port SMTP 25 est-il bloqué ou en timeout ?

Une plateforme d’hébergement, un FAI, un pare-feu ou la politique de la destination peut restreindre le port 25, car il sert au relais entre serveurs de messagerie et fait l’objet d’abus fréquents. Vérifiez la politique réseau et utilisez l’endpoint de soumission documenté par le fournisseur plutôt que de contourner une restriction avec un port arbitraire.

Puis-je passer du port 587 au port 465 sans rien changer d’autre ?

En général, non. Le port 587 commence le plus souvent en SMTP puis passe en TLS via STARTTLS, alors que le port 465 commence immédiatement par une négociation TLS. Changez le port et le mode TLS du client ensemble, en suivant la documentation du fournisseur et de la bibliothèque.

Le port 587 est-il chiffré par défaut ?

Le port identifie la soumission de messages, mais le chiffrement dépend toujours de la négociation STARTTLS et de la politique du client. Configurez le client pour qu’il exige une mise à niveau réussie, valide le certificat et refuse d’envoyer les identifiants ou les données du message si une soumission protégée ne peut pas être établie.

Que signifie « connection refused » en SMTP ?

Cela signifie que la destination TCP a rejeté la connexion avant la négociation SMTP. Les causes courantes sont un mauvais hôte ou port, un service qui n’écoute pas, un rejet par un pare-feu ou un endpoint du fournisseur inaccessible depuis ce réseau.

Un test de port SMTP réussi prouve-t-il la livraison des e-mails ?

Non. Il prouve uniquement les étapes que le test a réellement franchies, comme TCP ou TLS. L’authentification, l’acceptation du message, l’acceptation par le serveur de destination, la gestion des bounces, le classement dans la boîte aux lettres et l’engagement du destinataire exigent des preuves distinctes et doivent être rapportés séparément.

Sources

Continuer à apprendre

Le protocole SMTP : comment circulent les e-mails applicatifsDécouvrez comment la soumission SMTP, le relais, les enveloppes, les codes de réponse, TLS, les nouvelles tentatives et le contenu du message façonnent un workflow e-mail applicatif.Comment évaluer un service de relais SMTPÉvaluez les services de relais SMTP selon la sécurité de la soumission, l’authentification, les files d’attente, le comportement des nouvelles tentatives, les limites, les événements de livraison, la suppression, l’isolation et l’adéquation à la migration.Guide d’implémentation d’une API e-mail pour les équipes produitConcevez une intégration d’API e-mail sûre avec des domaines vérifiés, des envois mis en file d’attente, des identifiants stables, des nouvelles tentatives maîtrisées, des événements de livraison, la suppression et l’isolation des locataires.Comment évaluer un service de délivrabilité e-mailÉvaluez les services de délivrabilité e-mail selon leur périmètre, leurs preuves, l’authentification, les boucles de rétroaction, les suppressions, la confidentialité, la portabilité et l’adéquation opérationnelle.