Un développeur a passé des heures à déboguer pourquoi son application ne pouvait pas envoyer d’email. Le code était correct. Les identifiants étaient valides. Le service d’email fonctionnait. Le problème ? Il essayait de se connecter sur le port 25, que son fournisseur cloud bloquait par défaut. Passer au port 587 a tout réglé instantanément.
La messagerie email utilise différents ports selon les besoins, et ces distinctions comptent plus qu’on ne le pense. Utiliser le mauvais port peut entraîner des connexions bloquées, des failles de sécurité ou des échecs de livraison. Savoir quel port utiliser dans quel cas fait gagner du temps de débogage et améliore votre infrastructure email.
Port 25: the original SMTP port
Le port 25 est le port SMTP traditionnel, défini dans la spécification d’origine du protocole. Il est utilisé pour le transfert d’email de serveur à serveur—lorsqu’un serveur de messagerie remet un email à un autre.
Quand votre serveur de messagerie doit livrer un email à gmail.com, il se connecte aux serveurs de Gmail sur le port 25. C’est ainsi que les emails circulent entre serveurs depuis les débuts de la messagerie sur internet.
Cependant, le port 25 pose des problèmes pour les usages modernes. Il a été conçu avant que le spam ne devienne un enjeu majeur et a été lourdement abusé. De nombreux FAI et fournisseurs cloud bloquent les connexions sortantes sur le port 25 depuis leurs réseaux pour empêcher les machines compromises d’envoyer du spam directement.
Si vous exploitez un serveur de messagerie qui doit recevoir des emails d’autres serveurs, vous devez accepter les connexions sur le port 25. C’est là que les autres serveurs se connecteront. Mais pour envoyer des emails depuis des applications, le port 25 est généralement un mauvais choix—il est probablement bloqué et, même s’il ne l’est pas, il ne requiert pas d’authentification par défaut.
Port 587: the submission port
Le port 587 est le port désigné pour la soumission d’emails—lorsqu’un client ou une application soumet un message à un serveur de messagerie pour livraison. Il a été conçu spécifiquement pour séparer la soumission client du transfert serveur à serveur.
Contrairement au port 25, le port 587 exige une authentification. Vous ne pouvez pas simplement vous connecter et envoyer ; vous devez prouver que vous êtes autorisé. Cela rend l’abus par des spammeurs bien plus difficile et l’usage légitime bien plus sûr.
Le port 587 utilise STARTTLS pour le chiffrement. La connexion démarre en clair, puis passe en TLS après le handshake initial. On parle de "TLS explicite" ou de "TLS opportuniste". Les serveurs modernes exigent cette montée en chiffrement ; la phase non chiffrée n’existe que pour la compatibilité avec le déroulement du protocole.
Pour les applications qui envoient des emails via un service d’email ou un relais SMTP, le port 587 est généralement le bon choix. Il est conçu pour cet usage, requiert une authentification, prend en charge le chiffrement et n’est en général pas bloqué par les fournisseurs réseau.
Port 465: implicit TLS
Le port 465 a une histoire compliquée. Il a été brièvement attribué au SMTPS (SMTP over SSL) dans les années 1990, puis déprécié, puis récemment à nouveau standardisé pour la soumission en "TLS implicite".
Avec le TLS implicite, la connexion est chiffrée dès le premier octet. Il n’y a pas de handshake en clair suivi d’une montée—vous vous connectez directement en TLS. C’est sans doute plus sécurisé que STARTTLS, qui a une brève fenêtre non chiffrée théoriquement exploitable.
Les services email modernes prennent de plus en plus en charge le port 465 pour la soumission. Si votre fournisseur d’email le propose et que votre client ou bibliothèque le supporte, le port 465 est un excellent choix. Le chiffrement immédiat offre une sécurité légèrement meilleure que l’approche STARTTLS sur le port 587.
La confusion historique autour du port 465 fait que certaines documentations anciennes conseillent de l’éviter. Ce conseil est dépassé. Le port a été restandardisé et est désormais une option légitime et recommandée pour la soumission d’emails.
Port 2525: the alternative
Le port 2525 n’est pas une norme officielle—c’est une convention née du fait que les ports 25, 465 et 587 sont parfois bloqués ou restreints.
Certains FAI bloquent le port 25 pour prévenir le spam. Certains pare-feu d’entreprise restreignent les ports email. Certains fournisseurs cloud limitent les ports utilisables. Quand les ports standards ne fonctionnent pas, le 2525 fonctionne souvent.
Les services email proposent couramment le port 2525 comme port de soumission alternatif. Il fonctionne exactement comme le port 587—même protocole, même authentification, même chiffrement STARTTLS—simplement avec un numéro de port différent.
Si vous avez des difficultés à vous connecter sur les ports standards, essayez 2525. Il est largement supporté par les services email et rarement bloqué. Il n’est pas "meilleur" que 587 ou 465 ; c’est juste une porte de sortie quand ceux-ci ne fonctionnent pas.
Choosing the right port
Selon les scénarios, différents ports s’imposent.
Pour la soumission d’emails depuis une application (envoi via un service d’email), utilisez le port 587 ou 465. Les deux exigent une authentification et supportent le chiffrement. Le port 587 avec STARTTLS est le plus universellement supporté. Le port 465 avec TLS implicite est légèrement plus sûr. Si les deux sont bloqués, essayez 2525.
Pour le transfert de serveur à serveur (exploiter votre propre serveur de messagerie), vous devez accepter les connexions sur le port 25. Les autres serveurs s’y connecteront pour vous livrer des emails. Vous pouvez aussi envoyer sur le port 25 vers d’autres serveurs, même si beaucoup préfèrent désormais des connexions chiffrées.
Pour recevoir des emails sur votre propre serveur, écoutez sur le port 25 pour les connexions entrantes serveur à serveur. Vous pouvez également écouter sur 587 et/ou 465 pour la soumission authentifiée par vos propres utilisateurs et applications.
N’utilisez jamais le port 25 pour de la soumission non authentifiée depuis des applications. Même si cela fonctionne, c’est un risque de sécurité et cela provoquera probablement des problèmes de délivrabilité.
Security considerations
Le choix du port affecte la sécurité de plusieurs façons.
Les exigences d’authentification diffèrent selon les ports. Le port 25 n’exige traditionnellement pas d’authentification (même si les serveurs modernes le font souvent). Les ports 587 et 465 exigent une authentification par conception. Utilisez toujours des ports authentifiés pour la soumission.
Les approches de chiffrement varient. Le port 587 utilise STARTTLS (montée en chiffrement). Le port 465 utilise du TLS implicite (chiffré dès le départ). Le port 25 peut supporter STARTTLS mais ne l’exige pas. Pour la sécurité, privilégiez les ports qui imposent le chiffrement.
L’exposition réseau compte. Si vous exploitez un serveur de messagerie, le port 25 doit être ouvert sur internet pour recevoir des emails. Les ports 587 et 465 peuvent être restreints à des clients connus ou à des VPN si vous n’avez pas besoin d’accès public à la soumission.
Les règles de pare-feu doivent refléter ces différences. Autorisez le port 25 en entrée pour recevoir des emails. Autorisez les ports 587/465 pour la soumission, éventuellement avec des restrictions supplémentaires. Bloquez le port 25 en sortie sur les systèmes qui ne doivent pas envoyer d’emails directement.
Common port problems
Plusieurs problèmes reviennent fréquemment autour des ports email.
Les ports bloqués sont le problème le plus courant. Les fournisseurs cloud bloquent souvent le port 25 par défaut. Les réseaux d’entreprise peuvent restreindre les ports email. Les FAI bloquent parfois l’envoi depuis des connexions résidentielles. Quand les connexions échouent, essayez des ports alternatifs.
Le mauvais port pour l’usage crée de la confusion. Tenter de soumettre des emails sur le port 25 peut fonctionner mais manque d’authentification appropriée. Tenter de recevoir des emails serveur à serveur sur le port 587 ne fonctionnera pas—les autres serveurs s’attendent au port 25.
Des incompatibilités de configuration TLS surviennent quand le client attend un mode de chiffrement et que le serveur en offre un autre. Le port 587 attend STARTTLS ; le port 465 attend du TLS immédiat. Utiliser le mauvais mode pour le port provoque des échecs de connexion.
Des règles de pare-feu trop restrictives bloquent des emails légitimes. Trop permissives, et vous êtes exposé aux abus. Trouver le bon équilibre nécessite de comprendre quels ports servent à quels usages.
Testing port connectivity
Avant de déboguer des problèmes email complexes, vérifiez la connectivité de base des ports.
Telnet ou netcat peuvent tester si un port est joignable. "telnet mail.example.com 587" tente une connexion. Si elle aboutit, le port est ouvert. Si cela expire ou est refusé, quelque chose le bloque.
OpenSSL peut tester les connexions chiffrées. "openssl s_client -connect mail.example.com:465" teste le TLS implicite. "openssl s_client -starttls smtp -connect mail.example.com:587" teste STARTTLS.
Des outils en ligne peuvent tester depuis l’extérieur de votre réseau. Si les connexions fonctionnent depuis des outils externes mais pas depuis votre application, le problème vient probablement des restrictions sortantes de votre réseau.
La documentation des services email précise quels ports ils supportent et recommandent. Consultez leurs docs plutôt que de deviner—chaque service a des configurations différentes.
Frequently asked questions
Quel port dois-je utiliser pour envoyer des emails depuis mon application ?
Le port 587 avec STARTTLS est le choix le plus largement supporté. Le port 465 avec TLS implicite est aussi une bonne option si votre service d’email le supporte. Si les deux sont bloqués, essayez le port 2525.
Pourquoi le port 25 est-il bloqué sur mon serveur cloud ?
Les fournisseurs cloud bloquent le port 25 par défaut pour prévenir le spam. Les serveurs compromis essaient souvent d’envoyer du spam directement. Vous pouvez généralement demander l’accès au port 25 si vous avez un besoin légitime, mais pour l’email applicatif, utilisez plutôt le port 587.
Le port 465 est-il sécurisé à utiliser ?
Oui. Malgré son histoire compliquée, le port 465 est désormais restandardisé pour la soumission en TLS implicite. Il est sans doute plus sûr que le port 587, car le chiffrement démarre immédiatement plutôt qu’après une montée STARTTLS.
Dois-je ouvrir plusieurs ports pour l’email ?
Cela dépend de votre configuration. Pour recevoir des emails sur votre propre serveur, vous devez ouvrir le port 25. Pour la soumission, vous pouvez proposer 587 et/ou 465. Pour l’envoi via un service d’email, vous n’avez besoin que d’un accès sortant vers leurs ports.