Refonte des e-mails : sortie de la tâche rake de test

Oui.

Mais dans tous les cas, cela aurait fonctionné. Sans rien toucher, STARTTLS ne serait utilisé que si le serveur le proposait.

La seule situation où il a jamais été nécessaire de le désactiver explicitement était lorsque :

  • le serveur propose STARTTLS
  • les courriels envoyés SANS utiliser STARTTLS fonctionnaient
  • les courriels envoyés AVEC STARTTLS échouaient
2 « J'aime »

Probablement vrai pour la plupart.

Pour nous, nous dépendons en fait d’une ancienne solution de messagerie qui n’utilise pas STARTTLS pour les e-mails sortants des systèmes internes (ce qui est géré plus tard dans la chaîne) et puisque la documentation indiquait que DISCOURSE_SMTP_ENABLE_START_TLS était facultatif, mais vrai par défaut, nous avons réglé cela sur false intentionnellement.

Je peux ignorer cet avis, mais il réapparaît et d’autres administrateurs se demanderont s’il y a quelque chose qui ne va pas avec notre configuration (il n’y a rien ; le mail de test fonctionne parfaitement !). L’avis est-il censé être si persistant ?

DISCOURSE_SMTP_ENABLE_START_TLS n’utilisera STARTTLS que si le serveur le propose. Si votre serveur de messagerie ne le propose pas, il ne sera pas utilisé.

(c’est ce qu’on appelle le TLS opportuniste)

La raison pour laquelle j’ai ajouté l’avertissement est qu’avant mon changement, régler DISCOURSE_SMTP_ENABLE_START_TLS sur faux ne désactivait pas réellement STARTTLS.

J’imaginais qu’il y avait un nombre non nul d’administrateurs qui n’avaient aucune idée du fonctionnement de cela et qui ont bricolé des variables jusqu’à ce que cela fonctionne et ont laissé DISCOURSE_SMTP_ENABLE_START_TLS=false défini, même si leur configuration en avait besoin. L’avertissement s’adresse en grande partie à ces personnes.

1 « J'aime »

Vous avez raison ! Je viens de tester et je peux confirmer que l’envoi d’e-mails fonctionne toujours pour nous après la suppression du paramètre. :+1:

1 « J'aime »