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

J’ai récemment examiné les e-mails : tâche et le code associé dans le but de tester chacun des chemins d’échec et de retoucher le texte d’erreur.

J’ai également découvert que les effets de la définition de DISCOURSE_SMTP_ENABLE_STARTTLS=false sont (principalement) nuls. La définition de cette option n’a pas réellement désactivé STARTTLS et, en fait, elle peut coexister sans problème avec TLS au moment de la connexion (DISCOURSE_SMTP_FORCE_TLS=true).

J’ai donc :

Avant de fusionner cela, je pense qu’un avertissement d’administrateur dans le tableau de bord lorsqu’une valeur est définie pour DISCOURSE_SMTP_ENABLE_STARTTLS=false est approprié. J’imagine qu’il y a au moins un auto-hébergeur qui l’a défini mais n’en a pas besoin et s’appuie en fait sur STARTTLS.

4 « J'aime »

Cela semble être du bon travail ! Une chose que j’ai (je pense) remarquée, c’est que la tâche rake n’utilise pas réellement le même code que l’envoi réel (comme depuis la page de test d’e-mail /admin/email). Je suis à peu près sûr d’avoir eu un cas où cela a fonctionné dans l’UX mais pas dans la tâche rake (ou peut-être était-ce l’inverse ?)

Tant que c’est frais dans votre esprit, si vous pouviez vérifier qu’au moins lorsqu’il envoie réellement, il le fait en utilisant le même code que Discourse, ce serait formidable.

2 « J'aime »

Nous travaillons également sur cela, et sur l’amélioration de la journalisation en cas d’échec d’un travail d’e-mail mis en file d’attente. :+1:

4 « J'aime »

Y a-t-il quelque chose que je doive faire sur le forum que vous hébergez ?

4 « J'aime »

Non, cette alerte ne devrait pas s’afficher sur notre hébergement. Nous allons corriger cela, merci pour le rapport comme toujours.

5 « J'aime »

@supermathie est-ce que cela vaut la peine d’envoyer un message privé à chaque administrateur sur chaque site où cette variable est définie ? Notre système actuel de vérification des problèmes le fera, et je ne suis pas sûr que ce soit justifié ici, étant donné que, dans la plupart des cas, cela a un effet nil. Idéalement, je voudrais seulement montrer cela sur le tableau de bord sans notifier les utilisateurs administrateurs, je ne suis pas sûr que notre structure actuelle de vérification des problèmes prenne en charge ce cas d’utilisation.

Je pense que oui - je trouve extrêmement probable que, étant donné la confusion de nombreux administrateurs concernant la configuration de la messagerie, quelqu’un ait cette variable définie alors qu’il dépend en fait de starttls.

Personne ne devrait l’avoir définie, probablement.

Je préférerais un avertissement superflu plutôt que de casser silencieusement la configuration de messagerie de quelqu’un.

L’alternative est de supprimer la vérification et de neutraliser la variable pour qu’elle ne fasse rien du tout.

1 « J'aime »

Il serait agréable que l’avertissement n’apparaisse pas lorsque le serveur SMTP sortant est localhost (c’est-à-dire qu’il correspond au nom de domaine de Discourse), car le TLS entre le conteneur Docker et l’hôte n’est pas nécessaire puisqu’il s’agit de la même machine.

1 « J'aime »

Dans ce cas, vous pouvez supprimer la variable de l’environnement.

Il n’utilisera STARTTLS que s’il est proposé.

1 « J'aime »