Je voulais juste signaler cela car il semble y avoir un malentendu courant : le port 587 n’est pas « l’avenir » — le TLS implicite sur le port 465 l’est.
J’ai été amené à cette révélation par cet article.
Et après avoir lu la RFC officielle de 2018, c’est clair : ce n’est pas que STARTTLS soit la voie à suivre, c’est que SMTPS n’est pas la voie à suivre, et que le TLS implicite sur le port 465 (ou 587) est ce que les administrateurs devraient choisir à l’avenir.
Le support du TLS sur le port 465 ne devrait pas être classé (et probablement dépriorisé) comme « maintien de la compatibilité ascendante » ou toute notion similaire.
Le mécanisme STARTTLS sur le port 587 est relativement largement déployé en raison de la situation avec le port 465 (discuté dans la section 7.3. Cela diffère des services IMAP et POP où le TLS implicite est plus largement déployé sur les serveurs que STARTTLS. Il est souhaitable de migrer les protocoles de base utilisés par les logiciels MUA vers le TLS implicite au fil du temps, pour la cohérence ainsi que pour les raisons supplémentaires discutées dans l’annexe A. Cependant, pour maximiser l’utilisation du chiffrement pour la soumission, il est souhaitable de prendre en charge les deux mécanismes pour la soumission de messages via TLS pendant une période de transition de plusieurs années. En conséquence, les clients et les serveurs DOIVENT implémenter STARTTLS sur le port 587 et le TLS implicite sur le port 465 pendant cette période de transition. Notez qu’il n’y a pas de différence significative entre les propriétés de sécurité de STARTTLS sur le port 587 et le TLS implicite sur le port 465 si les implémentations sont correctes et si le client et le serveur sont configurés pour exiger une négociation réussie de TLS avant la soumission de messages.
La transition ne se fait pas vers les soumissions sur le port 587 via STARTTLS, mais vers les soumissions via TLS implicite sur le port 465 (par opposition à SMTPS sur le port 465 qui est maintenant obsolète).