Postfix smtps et soumission confusion


13

J'ai configuré le suffixe pour que les clients de messagerie utilisent le port 465 (smtps) pour le courrier sortant. Je ne comprends pas vraiment la différence entre smtps (port 465) et soumission (port 587)

Quelle est la «meilleure pratique» lors de la configuration de postfix pour que les clients envoient leur courrier en toute sécurité? Utilisez simplement smtps? Ou utiliser à la fois la soumission et les smtps?

Réponses:


21

Le port 465 a été utilisé pour les connexions SMTP sécurisées par SSL. Cependant, l'utilisation de ce port pour SMTP a été déconseillée avec la disponibilité de STARTTLS: «Révocation du port TCP smtps» De nos jours, vous ne devriez plus utiliser le port 465 pour SMTPS. Au lieu de cela, utilisez le port 25 pour recevoir des e-mails pour votre domaine à partir d'autres serveurs, ou le port 587 pour recevoir des e-mails de clients, qui doivent envoyer des e-mails via votre serveur vers d'autres domaines et donc d'autres serveurs.

Comme note supplémentaire, le port 587 est cependant dédié à la soumission de courrier - et la soumission de courrier est conçue pour modifier le message et / ou fournir une authentification:

  • proposer et exiger une authentification pour les clients qui tentent de soumettre des e-mails
  • fournir des mécanismes de sécurité pour empêcher la soumission de courrier en vrac non sollicité (spam) ou de courrier infecté (virus, etc.)
  • adapter le courrier aux besoins d'une organisation (réécriture de la partie, etc.)

La soumission au port 587 est censée prendre en charge STARTTLS et peut donc être chiffrée. Voir aussi RFC # 6409 .


Merci pour votre réponse, j'ai réussi à configurer la soumission avec postfix et les choses sont beaucoup plus claires pour moi maintenant. :-)
Aditya K

Vous êtes les bienvenus =)
liquidat

1
Le trafic sur le port 465 est entièrement crypté. Lorsque vous utilisez starttls, le client peut entrer dans une transmission sécurisée et quitter l'envoi de données sans chiffrement. serverfault.com/q/523804/201912
QkiZ

2

TL; DR

La nouvelle recommandation est de prendre en charge les soumissions / smtps et la soumission avec STARTTLS pour le moment, en supprimant progressivement la dernière fois qu'elle n'est plus utilisée. (Les mêmes recommandations s'appliquent également pour POP3 vs POP3S et IMAP vs IMAPS.)

Détails

La meilleure pratique a changé avec la RFC 8314 Section 3.3 :

Lorsqu'une connexion TCP est établie pour le service "soumissions" (port par défaut 465), une négociation TLS commence immédiatement. […]

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ù Implicit TLS est plus largement déployé sur les serveurs que STARTTLS. Il est souhaitable de Migrer protocoles de base utilisés par le logiciel MUA à TLS Implicite au fil du temps, par souci de cohérence, ainsi que pour les autres raisons décrites à l' annexe A . Cependant, pour maximiser l'utilisation du chiffrement pour la soumission, il est souhaitable de prendre en charge les deux mécanismes de soumission de messages sur TLS pendant une période de transition de plusieurs années. En conséquence, les clients et les serveurs DEVRAIENT implémenter à la fois STARTTLS sur le port 587 et implicite TLS sur le port 465 pour 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 TLS implicite sur le port 465 si les implémentations sont correctes et si le client et le serveur sont configurés pour exiger la négociation réussie de TLS avant la soumission du message.

L' annexe A citée développe ensuite la décision de préférer le TLS implicite pour tous les SMTP, POP3 et IMAP, car ces points principaux

  1. Nous souhaitons de toute façon avoir uniquement des connexions cryptées partout, il est donc inutile de maintenir une version rétrocompatible de tous ces protocoles lorsque, dans la pratique, cette compatibilité n'est pas utilisée.
  2. Il y a eu des exploits de la phase de négociation STARTTLS en raison de problèmes identiques dans plusieurs implémentations
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.