Ho recentemente esaminato le email:task e il codice correlato con l’obiettivo di testare tutti i percorsi di errore e ritoccare il testo degli errori.
Ho anche scoperto che gli effetti dell’impostazione di DISCOURSE_SMTP_ENABLE_STARTTLS=false sono (per lo più) nulli. L’impostazione di questo valore non disabilitava effettivamente STARTTLS e, di fatto, può coesistere senza problemi con TLS al momento della connessione (DISCOURSE_SMTP_FORCE_TLS=true).
Prima di unire questo, tuttavia, penso che un avviso per gli amministratori nella dashboard quando viene impostato DISCOURSE_SMTP_ENABLE_STARTTLS=false sia appropriato. Immagino che ci sia almeno un self-hoster che lo ha impostato ma non ne ha bisogno e si affida effettivamente a STARTTLS.
Ottimo lavoro! Una cosa che ho (credo di aver) notato è che il task rake non utilizza lo stesso codice dell’invio effettivo (come dalla pagina di test delle email /admin/). Sono abbastanza sicuro di aver avuto un caso in cui ha funzionato nell’UX ma non nel task rake (o forse era il contrario?)
Mentre è fresco nella tua mente, se potessi assicurarti che quando invia effettivamente lo faccia utilizzando lo stesso codice che usa Discourse, sarebbe fantastico.
@supermathie vale la pena inviare un messaggio privato a ogni amministratore su ogni sito che ha questa variabile impostata? Il nostro attuale sistema di controllo dei problemi lo farà, e non sono sicuro che sia giustificato qui, dato che per la maggior parte ha un effetto nil. Idealmente, vorrei mostrarlo solo sulla dashboard senza avvisare gli utenti amministratori, non sono sicuro che la nostra attuale struttura di controllo dei problemi supporti questo caso d’uso.
Penso di sì: trovo estremamente probabile che, dato quanto molti amministratori siano confusi riguardo alla configurazione dell’email, qualcuno abbia questa variabile impostata quando in realtà dipende da starttls.
Probabilmente nessuno dovrebbe averla impostata.
Preferirei un avviso errato piuttosto che interrompere silenziosamente la configurazione dell’email di qualcuno.
L’alternativa è rimuovere il controllo e neutralizzare la variabile in modo che non faccia nulla.
Sarebbe bello se l’avviso non apparisse quando il server SMTP in uscita è localhost (cioè corrisponde al nome del dominio di Discourse) poiché TLS tra il container Docker e l’host non è necessario in quanto sono la stessa macchina.
