Dépanner l'e-mail sur une nouvelle installation de 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 « J'aime »

Ces informations sont-elles à jour ? Cela n’a pas fonctionné pour moi ; j’ai dû reconstruire l’application après avoir modifié le port SMTP.

2 « J'aime »

Si discourse-doctor indique que la connexion au port 587 a échoué, mais que openssl s_client -connect your.smtp.server:587 -starttls smtp fonctionne correctement, essayez ceci, les deux commandes devraient prendre le même temps :

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

Si la version docker est beaucoup plus longue, vous avez peut-être une mauvaise configuration dans votre fichier /etc/docker/daemon.json. Vous pouvez essayer de mettre le serveur DNS de Google en premier lieu :

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

Le port 2525 fonctionne pour Mailjet.
Le port 587 a échoué.

2 « J'aime »

J’ai modifié le message initial pour suggérer l’utilisation du port 2525. C’est votre service d’hébergement qui bloque le port. Pour cette raison, de nombreux services de messagerie prennent également en charge le port 2525.

3 « J'aime »

Salut, je voulais juste ajouter une note à ce sujet ;

Mailgun exige désormais une carte de crédit pour pouvoir envoyer des e-mails (autres qu’à vous-même). Si vos journaux Mailgun contiennent un message concernant les « comptes gratuits », c’est votre problème.

Je me suis inscrit cette semaine (juillet 2024) et jusqu’à présent, cela fonctionne sans avoir à ajouter de carte de crédit, en utilisant le niveau gratuit de base. D’après ce que j’ai vu dans d’anciens fils de discussion, il semble qu’ils aient changé d’avis sur cette politique, ainsi que sur l’utilisation et les limitations de leurs niveaux gratuits, peut-être.

1 « J'aime »

Wow. C’est fou et très différent de ce que j’ai connu depuis aussi longtemps que je me souvienne.

Il a été très difficile pour les gens de comprendre comment passer au forfait prépayé et ne pas s’inscrire à un forfait mensuel assez coûteux.

Avez-vous envoyé à d’autres utilisateurs que vous-même ?

1 « J'aime »

Oui, j’ai envoyé aux utilisateurs et ça fonctionne. Le seul hic, c’est que pour une raison quelconque, les adresses e-mail AOL bloquent mes e-mails, mais je ne pense pas que ce soit la faute de MailGun. Je suis aussi surpris que vous :slight_smile:

Mise à jour : il semble que la raison pour laquelle certains e-mails sont bloqués est que l’adresse IP utilisée pour envoyer les e-mails gratuits de MailGun est partagée, elle a donc été signalée comme « Spam » par certaines plateformes de messagerie telles que AOL, Yahoo Mail, et d’autres. Il semble que tous ceux qui n’utilisent pas Gmail voient leurs e-mails rejetés ou refusés.

1 « J'aime »

Pouvez-vous s’il vous plaît expliquer comment vérifier les paramètres dans notre fichier containers/app.yml ? Nous, les débutants, ne savons pas comment faire ces choses sans instruction explicite. lol

Si vous ne savez pas comment utiliser un outil comme nano, relancez discourse-setup. Une fois que les modifications sont enregistrées, vous pouvez appuyer sur Ctrl+C puis sur

./launcher destroy app;./launcher start app
1 « J'aime »

ok, mais comment vérifier les paramètres dans mon fichier containers/app.yml afin que je puisse examiner la section e-mail et vérifier que les données sont correctes ?

Si vous n’aimez pas ma réponse, vous pouvez rechercher « nano » sur Google.

On pourrait arguer que l’OP devrait dire quelque chose à propos de nano, bien que, comme je l’ai dit, si vous ne savez pas ce que c’est, il suffit de relancer discourse-setup, car il lit les valeurs du fichier et vous ne pouvez pas foirer le formatage.

Je vois ce que vous voulez dire maintenant. Lorsque vous exécutez les commandes destroy puis start, cela affiche les données dont j’ai besoin une fois qu’elles sont terminées. Mes excuses ! :slight_smile:

1 « J'aime »

J’ai exécuté le docteur et j’ai obtenu une erreur indiquant SMTPAuthenticationError. Le docteur dit ensuite que ce n’est pas une erreur courante et qu’il n’a aucune suggestion pour la corriger. Si cela se produit, assurez-vous de vérifier à nouveau votre nom d’utilisateur et votre mot de passe SMTP, car le processus de configuration de Discourse ne vous indique pas s’ils sont incorrects, cela ne fonctionne tout simplement pas (n’envoie pas d’e-mails) et vous laisse perplexe. Certaines choses que j’ai faites et qui ont aidé ont été de me connecter à mon serveur via SSH en utilisant Ubuntu au lieu de LISH (parce que j’utilise Linode) car LISH est terriblement bogué et ne prend pas en charge le copier-coller. J’ai ensuite refait le processus de configuration et tout copié-collé cette fois au lieu de taper des mots de passe de 100 caractères, lol. Quoi qu’il en soit, j’espère que cela aidera certains de mes collègues débutants !

Votre nom d’utilisateur ou votre mot de passe est incorrect.

Je ne suis pas sûr de ne pas avoir réussi à corriger cela, mais l’erreur s’explique d’elle-même.

Il se pourrait que vous l’ayez mal copié/collé. Il se pourrait qu’il contienne des caractères qui doivent être échappés.

J’utilise Brevo comme expéditeur d’e-mails de notification, et pourtant chaque notification envoyée a été rejetée en raison d’une erreur. J’ai trouvé un message dans Brevo indiquant que « L’envoi a été rejeté car l’expéditeur que vous avez utilisé n’est pas valide. Validez votre expéditeur ou authentifiez votre domaine ». À cause de cela, mon forum ne peut pas fonctionner du tout. Je me demande comment résoudre ce problème - quel type d’expéditeur me faut-il ? Merci beaucoup !!!

Pour l’adresse de l’expéditeur, vous pouvez utiliser le sous-domaine de messagerie que vous utilisez pour envoyer des e-mails, tel que mail@adresse_domaine.

Pour authentifier le sous-domaine + l’expéditeur, il y a quelques étapes pour lesquelles ils ont un guide ici :

Salut les gens de Discourse !

J’ai lutté pendant plusieurs jours pour configurer les paramètres d’e-mail avec le port 465, et la solution ne se trouve ni ici ni dans aucun autre post que j’ai lu sur le forum (et j’ai vraiment cherché).

Bien sûr, c’est une question de ce que votre serveur de messagerie accepte. Dans mon cas, uniquement 465 via TLS.

Les deux lignes de configuration requises à ajouter dans app.yml sont :

DISCOURSE_SMTP_FORCE_TLS: true
DISCOURSE_SMTP_ENABLE_START_TLS: false
Quelques détails

Les paramètres par défaut ont entraîné une erreur Net::ReadTimeout lors de l’envoi d’un e-mail de test avec discourse-doctor. L’envoi d’e-mails de test depuis le conteneur fonctionne bien avec, par exemple, curl, exactement comme dans ce post qui m’a mené à la moitié de la solution : Cannot send email - problem with port 465 - #10 by schungx

Je n’ai pu découvrir le deuxième paramètre qu’en examinant le contenu de app.yml et en modifiant ce paramètre. J’ai l’impression que la plupart des programmes (par exemple, Thunderbird) définissent implicitement le bon protocole lors de la sélection du port 465, alors peut-être que Discourse devrait le faire ? Cela semble être très standard, comme souligné ici :

(lien vers le post complet)

Je recommanderais donc vivement de mettre à jour la section de ce guide concernant le port 465 ou de faire en sorte que discourse-setup choisisse automatiquement le meilleur paramètre.

2 « J'aime »

Normalement, je ne commente pas, mais c’était vraiment utile !
Merci, le mainteneur de Discourse devrait absolument inclure ce paramètre dans la configuration par défaut, je veux dire qu’il était fastidieux de configurer leur logiciel, je n’ai toujours rien à critiquer, sauf que dans un si grand projet, certaines informations ne sont pas rapidement disponibles et il faut “creuser”.
OK, ça marche pour moi !

Une publication a été fusionnée dans un sujet existant : Utilisation de % dans le mot de passe SMTP pour discourse-setup