Ces ports 465 et 587 sont tous deux utilisés pour l'envoi de courrier (soumission de courrier) mais quelle est la vraie différence entre eux?
Les ports 465 et 587 sont destinés à la communication entre client de messagerie et serveur de messagerie - envoi d'e-mails en utilisant le protocole SMTP.
Port 465 est pour smtps
Le chiffrement SSL est automatiquement activé avant toute communication au niveau SMTP.
Port 587 est pour msa
C'est presque comme le port SMTP standard. L'agent d'envoi de mails doit accepter les e-mails après authentification (par exemple, après SMTP AUTH). Cela aide à arrêter le spam sortant lorsque les administrateurs réseau des plages de DUL peuvent bloquer les connexions sortantes au port SMTP (port 25).
Le chiffrement SSL peut être activé par la commande STARTTLS au niveau SMTP si le serveur le prend en charge et si votre FAI ne filtre pas la réponse EHLO du serveur (signalé en 2014).
Port 25 est utilisé pour la communication entre MTA (Mail Transfer Agent) (serveur de messagerie à serveur de messagerie). Il peut être utilisé pour la communication entre client et serveur mais ce n'est actuellement pas le plus recommandé. Le port SMTP standard accepte les e-mails des autres serveurs de messagerie vers ses boîtes aux lettres "internes" sans authentification.
Le port SMTP standard accepte les e-mails des autres serveurs de messagerie sans authentification - n'est pas réellement techniquement correct. Le port 25 standard peut transférer des e-mails avec ou sans authentification selon la configuration du MTA.
@Ilia Le port SMTP standard d'un MTA normal ne peut pas rejeter (toutes) les connexions SMTP non authentifiées.
Que diriez-vous de Postfix? Il n'autorise pas par défaut le relais de courrier, mais seulement pour les connexions du même réseau?
Ces affectations de port sont spécifiées par l'Autorité des numéros attribués sur Internet (IANA):
Historiquement, le port 465 était initialement prévu pour le cryptage et l'authentification SMTPS "wrapper" sur SMTP, mais il a été rapidement obsolète (en quelques mois, et il y a plus de 15 ans) au profit de STARTTLS sur SMTP (RFC 3207). Malgré ce fait, il y a probablement de nombreux serveurs qui prennent en charge l'enveloppe de protocole obsolète, principalement pour prendre en charge les anciens clients qui ont mis en œuvre SMTPS. À moins que vous n'ayez besoin de prendre en charge de tels anciens clients, SMTPS et son utilisation sur le port 465 devraient rester simplement une note historique.
Le terme complètement confus et imprécis, SSL, a souvent été utilisé pour indiquer l'enveloppe SMTPS et TLS pour indiquer l'extension de protocole STARTTLS.
SMTPS et son utilisation sur le port 465 ne devraient rester rien de plus qu'une note historique. Sauf que Gmail et la plupart des autres fournisseurs de messagerie utilisent le port 465 pour SSL alias SMTPS. C'est une réalité qui ne disparaîtra pas, peu importe ce que spécifie l'IANA.
@EricJ. ...Mais gmail prend également en charge le port 587. Savez-vous quel port utilise Google en interne? Sinon, le fait qu'ils supportent le port 465 ne compte pas vraiment comme preuve que c'est préféré ou même largement utilisé.
La réponse correcte à cette question a été modifiée par la publication du RFC 8314. En conséquence, les ports 465 et 587 sont tous deux des ports valides pour un agent de soumission de courrier (MSA). Le port 465 nécessite une négociation de TLS/SSL lors de la configuration de la connexion et le port 587 utilise STARTTLS si l'on choisit de négocier TLS. Le registre de l'IANA a été mis à jour pour permettre l'utilisation légitime du port 465 à cette fin. Pour le relais de courrier, seul le port 25 est utilisé, de sorte que STARTTLS est le seul moyen de faire du TLS avec le relais de courrier. Il est utile de considérer le relais de courrier et la soumission de courrier comme deux services très différents (avec de nombreuses différences de comportement telles que l'authentification requise, des délais d'attente différents, des règles de modification de message différentes, etc.) qui utilisent un protocole de communication similaire.
Si vous exécutez un service SMTP public: à la fois pour la compatibilité. S'il est privé, préférez le TLS implicite sur le port 465 sauf si vous devez prendre en charge des clients qui ne le prennent pas en charge. Extrait pris en charge: "Cependant, pour maximiser l'utilisation du chiffrement pour la soumission, il est souhaitable de prendre en charge les deux mécanismes de soumission de message via TLS pendant une période de transition de plusieurs années. Par conséquent, les clients et les serveurs DOIVENT implémenter à la fois STARTTLS sur le port 587 et le TLS implicite sur le port 465 pour cette période de transition" tools.ietf.org/html/rfc8314#section-3.3
Préférez le port 465 pour le chiffrement TLS implicite pour la soumission SMTP, conformément aux recommandations de RFC8314.
J'utilise toujours le port 465.
La réponse de danorton est obsolète. Comme lui et Wikipédia le disent, le port 465 était initialement prévu pour le cryptage SMTPS et rapidement obsolète il y a 15 ans. Mais beaucoup de FAI utilisent encore le port 465, notamment pour se conformer aux recommandations actuelles du RFC 8314, qui encourage l'utilisation du TLS implicite plutôt que l'utilisation de la commande STARTTLS avec le port 587. (Voir la section 3.3). Utiliser le port 465 est le seul moyen de commencer une session implicitement sécurisée avec un serveur SMTP agissant en tant qu'agent de soumission de courrier (MSA).
Fondamentalement, ce que recommande le RFC 8314, c'est d'abandonner les échanges de courrier en clair et d'utiliser uniquement des sessions TLS implicites pour les trois protocoles de courrier IETF courants pour assurer la cohérence lorsque c'est possible. Les ports sécurisés recommandés sont donc le 465, le 993 et le 995 pour SMTPS, IMAP4S et POP3S, respectivement.
Bien que le RFC 8314 permette certainement l'utilisation continue du TLS explicite avec le port 587 et la commande STARTTLS, le faire expose l'agent utilisateur de messagerie (MUA, le client de messagerie) à une attaque de rétrogradation où un homme du milieu intercepte la requête STARTTLS pour passer à la sécurité TLS mais la refuse, forçant ainsi la session à rester en clair.
Il a raison. Juste parce que les FAI l'abusent et n'ont pas mis à jour leur documentation ne rend pas cela incorrect. Il n'a pas dit que ce n'était pas utilisé - simplement que ce n'est pas une pratique qui suit les RFC. En d'autres termes, vous devriez utiliser 25 et 587 avec le courrier électronique, et n'utiliser que le 465 si vous DEVEZ, pour une raison quelconque.
PRÉFÉREZ le port 465 plutôt que le port 587, car le port 465 est utilisé pour le TLS implicite pour la soumission SMTP, ce qui suit les recommandations du RFC8314. Il recommande que "les connexions aux serveurs de soumission de courrier et aux serveurs d'accès au courrier soient effectuées en utilisant le «TLS implicite» (tel que défini ci-dessous), plutôt que de se connecter au port "en clair" et de négocier le TLS en utilisant la commande STARTTLS ou une commande similaire".
@dodexahedron La section 3.3 de la RFC est assez claire : rfc-editor.org/rfc/rfc8314#section-3.3 La RFC dit "il est souhaitable de migrer progressivement les protocoles de base ... vers le TLS implicite." Il est donc certainement une "pratique qui suit les RFC" d'utiliser le port 465.
Je ne veux pas donner de nom, mais quelqu'un semble être complètement dans l'erreur. L'organisme de normalisation mentionné a déclaré ce qui suit : soumissions 465 tcp Protocole de soumission de messages sur TLS [IESG] [IETF_Chair] 2017-12-12 [RFC8314]
Si vous le souhaitez, vous pouvez lire le RFC mentionné.
Cela semble clairement impliquer que le port 465 est le meilleur moyen de forcer la communication chiffrée et d'être sûr qu'elle est en place. Le port 587 n'offre aucune garantie à cet égard.
"Lorsqu'une connexion TCP est établie ... [vers] le port 465, une poignée de main TLS démarre immédiatement." Ce modèle est "intrinsèquement plus simple à implémenter, à déboguer et à déployer." Les connexions au port 587 se font en "texte clair" et TLS est négocié ensuite en utilisant la commande STARTTLS. "Bien qu'il n'y ait rien d'intrinsèquement faux à [cela], le fait que cela ait entraîné une erreur d'implémentation courante (commise indépendamment par plusieurs implémenteurs) suggère qu'il s'agit d'une architecture moins sécurisée que TLS implicite." Voir RFC8314 Annexe A pour la discussion.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
1 votes
La seule différence est les normes formalisées et le port 465 est pour le support hérité.
0 votes
Iana's "Registre des noms de services et des numéros de port de protocole de transport" est le guide officiel sur l'utilisation recommandée des ports; l'utilisation du port 465 pour SMTP sur SSL est non officielle. Lisez à propos des Ports dans SMTP. L'utilisation officielle de iana n'est pas toujours la même pour les protocoles de transport TCP et UDP. N.B.: si vous êtes l'administrateur de serveur SMTP, VOUS contrôlez le(s) port(s) utilisé(s); si vous êtes le client, vous n'avez accès qu'aux ports mis à votre disposition.
0 votes
Liés : stackoverflow.com/questions/3484947/…
0 votes
Lié: fastmail.com/help/technical/ssltlsstarttls.html