Risoluzione dei problemi con l'email su una nuova installazione di Discourse

You just installed Discourse via the install guide, but email doesn’t seem to work. Unfortunately this means you can’t log in as an admin to finalize the install. :cry: Let’s troubleshootize!

Try the doctor :woman_health_worker:

If you run ./discourse-doctor it will check several ways that your mail configuration might be broken, and offer advice. Try that first.

Did you enter email settings correctly?

The simplest way is to run ./discourse-setup again. Did you enter everything correctly? But wait! If your password has anything other than numbers and letters, you might be better off editing your app.yml with nano or your favorite editor.

You can also double check the settings in your containers/app.yml file. A valid email section looks like this:

DISCOURSE_DEVELOPER_EMAILS: 'name@example.com'
DISCOURSE_SMTP_ADDRESS: smtp.mailgun.org
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: postmaster@discourse.example.com
DISCOURSE_SMTP_PASSWORD: aUd34cdWKCu6CTjfoH7ykk

Closely examine all values for correctness. Note that:

  • it all aligns
  • no leading # characters
  • single quotes around the developer email field
  • password does not include ", ', %, ] or other special characters

If you had any errors in your app.yml and made changes, you MUST rebuild the container for those changes to take effect!

cd /var/discourse/
./launcher rebuild app

Well, you don’t always need to rebuild

Doing a rebuild will often fix things that seem broken, but it takes a while. There are times when a full rebuild is not necessary; the above is usually the best advice, but If you change just SMTP settings, you can do just this to apply them without doing a full rebuild:

cd /var/discourse
./launcher destroy app
./launcher start app

Are your SMTP connections being blocked?

To confirm that your server can indeed contact the email server, issue this command:

telnet smtp.mailgun.org 587

If you can’t connect this way, you’re almost certainly blocked. (And if you do get connected, the escape character for SMTP is ctrl+], then use quit to exit telnet.)

If this happens, first try port 2525, and if that fails, contact your cloud provider support and confirm that your email connections are not being blocked.

What do the Discourse logs say?

From the command line, issue this command:

cd /var/discourse
tail shared/standalone/log/rails/production.log

This will show the last few lines of the log. Look for anything mail related. If you need to view the fuller logs, try

less shared/standalone/log/rails/production.log

To page through the complete log, press space or type GG to jump to the end. Look closely for any email related messages or press /, type email, and hit enter to search.

What do your email provider logs say?

Assuming there are no errors in the Discourse logs, or your Discourse mail configuration, the emails probably went out. The question, is what did your email provider do with them?

Most email providers have a log viewing function. Check the logs for your email domain and see what happened with the incoming emails.

Did you properly set up DKIM and SPF records for your domain?

You must enter those crucial DNS records for DKIM and SPF, otherwise your emails may arrive only sporadically, if at all.

Is the email domain correct?

The default email from address is based on the install domain plus subdomain, so if your URL is discourse.example.com it will be:

noreply@discourse.example.com

But if your mail provider is expecting:

noreply@example.com

… you may have problems! To get around this, edit and uncomment this exec line in app.yml

## If you want to set the 'From' email address for your first registration, uncomment and change:
#- exec: rails r "SiteSetting.notification_email='noreply@example.com'"
## After getting the first signup email, re-comment the line. It only needs to run once.

You’ll need to issue a rebuild after uncommenting the above line and setting the from email address as required.

You can also change this from the command line, if needed:

./launcher enter app
rails r "SiteSetting.notification_email = 'discourse@yoursite.com'"
exit

If using Mailgun – have you activated your domain and provided credit card info?

If you are using Mailgun, after you enter your DKIM and SPF records, you must visit https://mailgun.com/app/domains/YOUR.DISCOURSE.DOMAIN.com and click the “Check DNS Records Now” button. At the top of that page you should see “State ACTIVE” (in a calming green). If it says “State Unverified” (in a scary warning-yellow) Mailgun will not accept mail.

Mailgun now requires a credit card in order to deliver mail (other than to you). If your mailgun logs have a message about “free accounts,” this is your problem.

Other mail services have similar requirements.

Are you using an IP address as the mail domain?

This does not work in our experience. You must use a domain name when sending email, not an IP address like 192.168.1.1.

If you really want to go on with an IP address, try mail settings similar to these:

DISCOURSE_SMTP_ADDRESS: 172.17.0.1         # e.g. use internal docker IP here
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: "YOUR-SMTP-USER-NAME"
DISCOURSE_SMTP_PASSWORD: "YOUR-SMTP-PASSWORD"
DISCOURSE_SMTP_ENABLE_START_TLS: true     # (optional, default true)
DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
DISCOURSE_SMTP_DOMAIN: example.com

Need to log in without receiving a registration email?

We don’t recommend this, because your email is still broken, and you have a broken Discourse until email is working. But if you absolutely must log in as admin with email broken, here’s what to do:

cd /var/discourse
./launcher enter app
rake admin:create

And answer the prompts. It takes a few seconds before they appear. When it asks for the password, you will not be able to see what you type. That is why it makes you type it twice.

Email smtp port selection (Using 465?)

The ability to be able to AUTH using ‘telnet’ is extremely important in your first steps of email troubleshooting.

Port 465 (SMTP over SSL) is largely deprecated in favor of STARTTLS on 25. You may need to try alternate ports such as port 2525 or port 587 (Mail Submission) when things do not seem to work as expected.

Command Line SMTP tests for experienced sysadmins

If you’re comfortable with the command line, these might help diagnose network or certificate problems. If these do not seem “easy-to-follow” then you should please ignore this section.

See also Test SMTP Authentication and StartTLS - Sysadmins of the North.

Office 365 Tweaks

If you’re using Office 365, be sure to include these (the first line is what you are likely missing):

DISCOURSE_SMTP_AUTHENTICATION: login
DISCOURSE_SMTP_ENABLE_START_TLS: true
DISCOURSE_SMTP_PORT: 587

and set the correct value for DISCOURSE_SMTP_NOTIFICATION_EMAIL (which is likely different from your forum hostname).

TLS and SSL issues

By default, Discourse uses STARTTLS to encrypt its connection to the email server. Some email servers (increasingly rare nowadays) don’t support this or aren’t configured to use it, so it can be disabled by adding this line:

DISCOURSE_SMTP_ENABLE_START_TLS: false    #default: true

Other email servers might support STARTTLS, but use a self-signed certificate. This is uncommon and can be enabled with:

DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none #default: peer

Email still doesn’t work! What next?

Anything else I forgot here? Feel free to edit this.


Debug issues with first connection to smtp server from inside the Discourse container

1. Enter your container:

./launcher enter app

2. Check dns resolving for your smtp server name via getent hosts:

(dig, nslookup, ping etc. are not installed inside the container.)

getent hosts your.smtp.server

On success, it will look like this or will be blank on failure.

# IPv4
123.123.123.123 your.smtp.server

# IPv6
2001:db8:0:0:0:ff00:42:8329 your.smtp.server

3. Try to open a connection to your smtp server via openssl:

(telnet, nc etc. are not installed inside the container.)

Fiddle with some different settings until you succeed with a connection.

openssl s_client -connect your.smtp.server:465
openssl s_client -connect your.smtp.server:587 -starttls smtp

# IPv4
openssl s_client -connect 172.17.0.123:465
openssl s_client -connect 172.17.0.123:587 -starttls smtp

# IPv6
openssl s_client -6 -connect "[2001:db8:0:0:0:ff00:42:8329]:465"
openssl s_client -6 -connect "[2001:db8:0:0:0:ff00:42:8329]:587" -starttls smtp

See: How to check SMTP connection → Step 3: Checking SMTP Connection Over TLS Using Openssl

4. Use your found working connection settings with Discourse.

:rocket:

Bonus: show Discourse IP from inside docker container

( ifconfig , ip etc. are not installed inside the container.)

hostname -I

Result like:

172.17.0.2

Last edited by @grayphilo 2025-03-04T18:51:41Z

Check documentPerform check on document:
57 Mi Piace

Queste informazioni sono aggiornate? Non ha funzionato per me; ho dovuto ricostruire l’app dopo aver modificato la porta SMTP.

2 Mi Piace

Se discourse-doctor segnala che la connessione alla porta 587 è fallita, ma openssl s_client -connect your.smtp.server:587 -starttls smtp funziona correttamente, prova questo, entrambi i comandi dovrebbero richiedere lo stesso tempo:

time openssl s_client -starttls smtp -connect your.smtp.server:587 < /dev/null > /dev/null

docker run --rm discourse/base:2.0.20231023-1945 bash -c 'time openssl s_client -starttls smtp -connect your.smtp.server:587 < /dev/null' > /dev/null

Se la versione di docker richiede molto più tempo, potresti avere una configurazione errata nel tuo file /etc/docker/daemon.json. Potresti provare a mettere il nameserver di Google al primo posto:

{
  "dns": ["8.8.8.8", "ww.xx.yy.zz", "ww.xx.yy.za"]
}

La porta 2525 funziona per Mailjet.
La 587 non ha funzionato.

2 Mi Piace

Ho modificato il post iniziale per suggerire l’uso della porta 2525. È il tuo servizio di hosting che blocca la porta. Per questo motivo, molti servizi di posta supportano anche la 2525.

3 Mi Piace

Ehi, volevo solo aggiungere una nota a riguardo;

Mailgun ora richiede una carta di credito per poter inviare email (diverse dalla tua). Se i tuoi log di Mailgun hanno un messaggio riguardo agli “account gratuiti”, questo è il tuo problema.

Mi sono iscritto questa settimana (luglio 2024) e finora ha funzionato senza dover aggiungere una carta di credito, utilizzando il livello gratuito di base. Sulla base di ciò che ho visto nei vecchi thread del forum, sembra che abbiano cambiato idea su questa politica e sull’utilizzo e sui limiti dei loro livelli gratuiti, forse

1 Mi Piace

Wow. È pazzesco e molto diverso da come sono andate le cose per quanto posso ricordare.

È stato molto difficile per le persone capire come passare al piano pay-as-you-go e non iscriversi a un piano mensile piuttosto costoso.

Hai inviato a utenti diversi da te stesso?

1 Mi Piace

Sì, ho inviato agli utenti e funziona. L’unico intoppo è che per qualche motivo gli indirizzi email AOL stanno bloccando le mie email, ma non credo sia colpa di MailGun. Sono sorpreso quanto te :slight_smile:

Aggiornamento: sembra che il motivo per cui alcune email vengono bloccate sia che l’IP utilizzato per inviare le email gratuite da MailGun è condiviso, quindi è stato segnalato come “Spam” da alcune piattaforme di posta elettronica come AOL, Yahoo Mail e altre. Sembra che chiunque non utilizzi Gmail stia riscontrando email respinte o rifiutate.

1 Mi Piace

Puoi per favore spiegare come controllare le impostazioni nel nostro file containers/app.yml? Noi novellini non sappiamo come fare queste cose senza istruzioni esplicite. lol

Se non sai come usare uno strumento come nano, esegui di nuovo discourse-setup. Dopo aver salvato le modifiche, puoi premere control-c e poi

./launcher destroy app;./launcher start app
1 Mi Piace

ok, ma come controllo le impostazioni nel mio file containers/app.yml in modo da poter esaminare la sezione email e verificare che i dati siano corretti?

Se non ti piace la mia risposta, puoi cercare “nano” su Google.

Si potrebbe sostenere che l’OP dovrebbe dire qualcosa su nano, anche se, come ho detto, se non sai cos’è, basta eseguire di nuovo discourse-setup, poiché legge i valori nel file e non puoi sbagliare la formattazione.

Ora capisco cosa intendi. Quando esegui i comandi destroy e poi start, vengono visualizzati i dati di cui ho bisogno una volta completati. Mi scuso! :slight_smile:

1 Mi Piace

Ho eseguito il doctor e ho ricevuto un errore che dice SMTPAuthenticationError. Il doctor dice poi che non è un errore comune e non ha suggerimenti su come risolverlo. Se ciò accade, assicurati di ricontrollare il tuo nome utente e password SMTP, poiché il processo di configurazione di Discourse non ti dice se è sbagliato, semplicemente non funziona (non invia email) e ti lascia bloccato. Alcune cose che ho fatto e che hanno aiutato sono state accedere al mio server tramite SSH usando Ubuntu invece di LISH (perché sto usando Linode) perché LISH è terribilmente difettoso e non supporta copia/incolla. Ho quindi rifatto il processo di configurazione e ho copiato/incollato tutto questa volta invece di digitare password di 100 caratteri, lol. Comunque, spero che questo aiuti alcuni dei miei compagni noob là fuori!

Il tuo nome utente o password non sono validi.

Non sono sicuro del perché non sono riuscito a risolvere quel problema, ma l’errore è piuttosto autoesplicativo.

Potrebbe essere che tu l’abbia copiato e incollato male. Potrebbe essere che contenga caratteri che devono essere sottoposti a escape.

Utilizzo Brevo come mittente delle email di notifica, eppure ogni singola notifica inviata è stata respinta a causa di un errore. Ho trovato un messaggio in Brevo che diceva: “L’invio è stato rifiutato perché il mittente che hai utilizzato non è valido. Valida il tuo mittente o autentica il tuo dominio”. A causa di ciò, il mio forum non può funzionare affatto. Mi chiedo come risolvere questo problema: che tipo di mittente mi serve? Grazie mille!!!

Per l’indirizzo del mittente, puoi impostarlo sul sottodominio di posta che stai utilizzando per inviare e-mail, ad esempio mail@indirizzo_dominio.

Per autenticare il sottodominio + mittente ci sono alcuni passaggi per i quali hanno una guida qui:

Ciao gente di Discourse!

Ho lottato per diversi giorni con l’impostazione dei parametri email con la porta 465, e la soluzione non è qui né in nessun post che ho letto sul forum (e ho davvero scavato).

Naturalmente si tratta di ciò che il tuo server di posta accetta. Nel mio caso, solo 465 su TLS.

Le due righe di configurazione richieste da aggiungere in app.yml sono:

DISCOURSE_SMTP_FORCE_TLS: true
DISCOURSE_SMTP_ENABLE_START_TLS: false
Alcuni dettagli

Le impostazioni predefinite hanno comportato un errore Net::ReadTimeout quando si provava un’email di test con discourse-doctor. L’invio di email di test dall’interno del container funziona bene con, ad esempio, curl, esattamente come in questo post che mi ha portato a metà della soluzione: Cannot send email - problem with port 465 - #10 by schungx

Ho potuto scoprire la seconda impostazione solo dopo aver esaminato il contenuto di app.yml e modificato questo parametro. Ho la sensazione che la maggior parte dei programmi (ad es. Thunderbird) imposti implicitamente il protocollo corretto quando seleziona la porta 465, quindi forse Discourse dovrebbe farlo? Questo sembra essere davvero standard, come evidenziato anche qui:

(link al post completo)

Quindi, mi batterei davvero per aggiornare la sezione di questa guida relativa alla porta 465 o per far sì che discourse-setup scelga automaticamente l’impostazione migliore.

2 Mi Piace

Normalmente non commento, ma questo è stato davvero utile!
Grazie amico, il manutentore di discourse dovrebbe assolutamente includere questa impostazione nella configurazione predefinita, voglio dire che è stato noioso configurare il loro software, ancora non ho nulla da criticare tranne che in un progetto così grande alcune informazioni non sono disponibili rapidamente e qualcuno dovrebbe “approfondire”.
OK funziona per me!

Un post è stato unito a un argomento esistente: Uso di % nella password SMTP per discourse-setup