Email di attivazione admin non inviato su nuova installazione self-hosted (ubuntu 20.04)

Supporto Installazione
1

Ciao Community,

Ho un’installazione di Discourse self-hosted ben funzionante su un VPS con Ubuntu 18.04 da circa un anno. Con la crescita del forum, ho iniziato a preparare il passaggio a un VPS più potente. Quindi, ho preso un’immagine minimale di Ubuntu 20.04, applicato alcune hardening tipiche e installato Discourse Docker seguendo la guida di installazione in 30 minuti. Ho utilizzato gli stessi valori esatti dell’installazione che funziona bene. Tuttavia: l’email di attivazione non viene inviata. La guida Risoluzione dei problemi relativi all’email in una nuova installazione di Discourse non ha aiutato: riesco a connettermi usando telnet, ma ottengo il seguente errore quando eseguo ./discourse-doctor:

>==================== TEST EMAIL ====================
Per un test affidabile, ottenete un indirizzo da http //www mail-tester com/
Oppure inviate semplicemente un messaggio di prova a voi stessi.
Indirizzo email per il test? ('n' per saltare) [anonimizzato]: test-9ymkghbvc@srv1 mail-tester com
Invio email a test-9ymkghbvc@srv1.mail-tester com. . .
Test di invio a test-9ymkghbvc@srv1.mail-tester com utilizzando smtp mailbox org:587.
==================== ERRORE ======================
                                    ERRORE INATTESO
>
>503 5.5.1 Errore: autenticazione non abilitata
>
>
>================== SOLUZIONE =====================
>Questo non è un errore comune. Non esiste una soluzione consigliata!
>
>Si prega di segnalare il messaggio di errore esatto sopra a https //meta discourse org/
(E una soluzione, se la trovate!)
=================================================

(ho dovuto rimuovere alcune parti degli URL sopra per poter pubblicare qui)

Fatto strano: ottengo lo stesso errore quando eseguo ./discourse-doctor anche sul mio VPS ben funzionante, quindi non so se l’errore sia rilevante.
Come potete vedere, sto utilizzando mailbox.org come provider di email, che funziona molto bene ed è un’ottima scelta in termini di privacy e configurazione robusta dell’infrastruttura email. Ho verificato host e porta e li sto usando anche in Thunderbird e nell’altra installazione di Discourse da anni.

Qualche idea? L’unica differenza che vedo tra i due VPS è che quello funzionante esegue Ubuntu 18.04, mentre il problema si verifica sul VPS con Ubuntu 20.04.

Grazie, cazee

2

Durante l’hardening, hai bloccato per sbaglio la porta 587?

C’è un errore di battitura nel file yaml.app?

smtp mailbox org:587

Dovrebbe essere

smtp.mailbox org:587

Notare il punto.

3

Grazie per le vostre idee.

La porta 587 è aperta, riesco a connettermi al server SMTP tramite telnet come indicato nella guida alla risoluzione dei problemi.
Ho anche testato con ufw disabilitato: stesso risultato.

Nessun errore di battitura nel file YAML: ho rimosso quei punti intenzionalmente nel mio messaggio (nuovo account del forum: sono consentite solo 2 URL in un post).

Cosa altro posso controllare o fare?

4

Inserisci il codice in blocchi di codice corretti, ecco perché hai incontrato i problemi che hai avuto.

5

Ho finalmente risolto questo problema.

Il motivo era l’indirizzo email del mittente utilizzato di default da Discourse. Viene generato a partire dal nome host inserito durante la configurazione (nel mio caso qualcosa di simile a v220200xxxxxxxxxxxx.powersrv.de), risultando nell’indirizzo del mittente noreply@v220200xxxxxxxxxxxx.powersrv.de, che viene rifiutato dal server SMTP.

Allora, perché uso questo nome host poco amichevole? Semplicemente perché il server è destinato a sostituire quello esistente, che sta diventando troppo piccolo per la nostra comunità Discourse ormai cresciuta. Sto preparando e testando il nuovo server prima di cambiare le impostazioni DNS per puntare a questo nuovo server in un secondo momento. Voglio solo risparmiare il tempo necessario per creare impostazioni DNS temporanee amichevoli qui.

Come risolvere il problema?
Cerca queste righe alla fine del tuo file app.yml:

## Se vuoi impostare l'indirizzo email 'From' per la tua prima registrazione, decommenta e modifica:
## Dopo aver ricevuto la prima email di iscrizione, ricommenta la riga. Deve essere eseguita una sola volta.

Decommenta e modifica l’ultima riga con un indirizzo che il tuo server SMTP accetta come mittente valido, ad esempio:
- exec: rails r "SiteSetting.notification_email='UTENTE@DOMINIO.TLD'"

Ora esegui ./launcher rebuild app per applicare le modifiche ed ecco fatto: ora l’email di attivazione viene inviata e puoi attivare l’account amministratore e completare la configurazione.

Come l’ho scoperto?
Ho creato un nuovo account email con il mio provider di spazio web e ho eseguito di nuovo la configurazione di Discourse con queste credenziali SMTP: ho ricevuto l’email di attivazione come previsto. Così ho capito che il problema doveva essere legato alle impostazioni SMTP (e non ad altri aspetti relativi alla configurazione di Ubuntu / Docker / Discourse).
Dopo aver attivato l’account amministratore con questo altro server SMTP, sono andato su Impostazioni > Email > Saltate e ho trovato i tentativi falliti di invio dell’email di attivazione: 553 5.7.1 <noreply@v220200xxxxxxxxxxxx.powersrv.de>: Indirizzo del mittente rifiutato: non di proprietà dell'utente UTENTE@DOMINIO.TLD

Conclusione
Vorrei richiamare l’attenzione del team di sviluppo di Discourse sulla richiesta di funzionalità Suggerimento - consentire un’impostazione opzionale del campo “Da” per l’email di sistema durante la configurazione. Si prega di considerare le installazioni di prova (ad esempio come copia per eseguire alcuni test prima dell’effettivo aggiornamento di un’istanza) che non dispongono di un indirizzo host amichevole. Sarebbe molto più semplice configurarle senza dover modificare il file app.yml. Inoltre, a mio avviso, è bene dare all’amministratore la possibilità di utilizzare indirizzi email non vincolati al nome host di Discourse.

Grazie :slight_smile:

Grazie anche a @codinghorror per avermi indicato come inserire i blocchi di codice.

6

Sto lavorando a una modifica per discourse-setup che richiederà di impostare notification_email durante il processo di configurazione. Questo dovrebbe risolvere problemi come il tuo in futuro.

7

Questa modifica è stata già unita al ramo principale e verrà richiesta durante le nuove installazioni!