Solucionar problemas de correo electrónico en una nueva instalación 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 Me gusta

¿Es esta información está actualizada? No me funcionó; tuve que reconstruir la aplicación después de cambiar el puerto SMTP.

2 Me gusta

Si discourse-doctor indica que la conexión al puerto 587 falló, pero openssl s_client -connect your.smtp.server:587 -starttls smtp funciona correctamente, prueba esto, ambos comandos deberían tardar la misma cantidad de tiempo:

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 versión de docker tarda mucho más, es posible que tengas una configuración incorrecta en tu archivo /etc/docker/daemon.json. Puedes intentar poner el servidor de nombres de Google en primer lugar:

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

el puerto 2525 funciona para mailjet.
587 falló.

2 Me gusta

Edité el OP para sugerir el uso del puerto 2525. Es su servicio de alojamiento el que bloquea el puerto. Debido a eso, muchos servicios de correo también admiten el 2525.

3 Me gusta

Oye, solo quería añadir una nota sobre esto;

Mailgun ahora requiere una tarjeta de crédito para poder enviar correos (que no sean a ti). Si tus registros de Mailgun tienen un mensaje sobre “cuentas gratuitas”, este es tu problema.

Me registré esta semana (julio de 2024) y hasta ahora, funciona sin tener que añadir una tarjeta de crédito, utilizando el nivel gratuito básico. Basándome en lo que he visto en hilos antiguos de foros, parece que han estado cambiando de opinión sobre esta política, y el uso y las limitaciones de sus niveles gratuitos, quizás

1 me gusta

Vaya. Eso es una locura y muy diferente a como han sido las cosas durante mucho tiempo.

Ha sido muy difícil para la gente averiguar cómo cambiar al plan de pago por uso y no suscribirse a un plan mensual bastante caro.

¿Has enviado a otros usuarios además de a ti mismo?

1 me gusta

Sí, he enviado a los usuarios y está funcionando. El único inconveniente es que, por alguna razón, las direcciones de correo electrónico de AOL están bloqueando mis correos electrónicos, pero no creo que sea culpa de MailGun. Estoy tan sorprendido como tú :slight_smile:

Actualización: parece que la razón por la que algunos correos electrónicos están siendo bloqueados es porque la IP utilizada para enviar los correos electrónicos gratuitos de MailGun es compartida, por lo que ha sido reportada como “Spam” por algunas plataformas de correo electrónico como AOL, Yahoo Mail y otras. Parece que todos los que no usan Gmail están experimentando rebotes o rechazos en la entrega de correos electrónicos.

1 me gusta

¿Puedes explicarme cómo revisar la configuración en nuestro archivo containers/app.yml? Los novatos no sabemos cómo hacer estas cosas sin instrucciones explícitas. lol

Si no sabes cómo usar una herramienta como nano, vuelve a ejecutar discourse-setup. Después de que guarde los cambios, puedes presionar Control+C y luego

./launcher destroy app;./launcher start app
1 me gusta

ok, pero ¿cómo reviso la configuración en mi archivo containers/app.yml para poder ver la sección de correo electrónico y verificar que los datos son correctos?

Si no te gusta mi respuesta, puedes buscar “nano” en Google.

Podría decirse que el OP debería decir algo sobre nano, aunque, como dije, si no sabes qué es, simplemente vuelve a ejecutar discourse-setup, ya que lee los valores del archivo y no puedes estropear el formato.

Ya veo lo que quieres decir ahora. Cuando ejecutas los comandos destroy y luego start, muestra los datos que necesito una vez que se completa. ¡Mis disculpas! :slight_smile:

1 me gusta

Ejecuté al doctor y obtuve un error que dice SMTPAuthenticationError. El doctor luego dice que este no es un error común y que no tienen sugerencias sobre cómo solucionarlo. Si esto sucede, asegúrate de verificar dos veces tu nombre de usuario y contraseña SMTP, ya que el proceso de configuración de Discourse no te dice si es incorrecto, simplemente no funciona (no envía correos electrónicos) y te deja perplejo. Algunas cosas que hice y que ayudaron fue conectarme por SSH a mi servidor usando Ubuntu en lugar de LISH (porque estoy usando Linode) porque LISH tiene muchos errores y no admite copiar y pegar. Luego rehice el proceso de configuración y copié y pegué todo esta vez en lugar de escribir contraseñas de 100 caracteres, jajaja. De todos modos, ¡espero que esto ayude a algunos de mis compañeros novatos!

Tu nombre de usuario o contraseña son incorrectos.

No estoy seguro de por qué no logré solucionarlo, pero el error se explica por sí mismo.

Podría ser que lo hayas copiado y pegado mal. Podría ser que tenga caracteres que necesiten ser escapados.

Utilizo Brevo como mi remitente de correo electrónico de notificación, pero cada notificación enviada fue rechazada debido a un error. Encontré un mensaje en Brevo que dice: “El envío ha sido rechazado porque el remitente que utilizaste no es válido. Valida tu remitente o autentica tu dominio”. Debido a esto, mi foro no puede funcionar en absoluto. Me pregunto cómo solucionar esto: ¿qué tipo de remitente necesito? ¡¡¡Muchas gracias!!!

Para la dirección del remitente, se puede configurar en el subdominio de correo que estás utilizando para enviar correos, como correo@dirección_dominio.

Para autenticar el subdominio + remitente, hay algunos pasos para los que tienen una guía aquí:

Hola gente de Discourse.

He estado luchando durante varios días para configurar los parámetros de correo electrónico con el puerto 465, y la solución no está aquí ni en ninguna publicación que haya leído en el foro (y he buscado mucho).

Por supuesto, es una cuestión de lo que acepta su servidor de correo. En mi caso, solo 465 sobre TLS.

Las dos líneas de configuración requeridas para agregar en app.yml son:

DISCOURSE_SMTP_FORCE_TLS: true
DISCOURSE_SMTP_ENABLE_START_TLS: false
Algunos detalles

La configuración predeterminada resultó en un error Net::ReadTimeout al intentar un correo electrónico de prueba con discourse-doctor. Enviar correos electrónicos de prueba desde dentro del contenedor funciona bien con, por ejemplo, curl, exactamente como en esta publicación que me llevó a la mitad de la solución: Cannot send email - problem with port 465 - #10 by schungx

Solo pude averiguar la segunda configuración después de mirar el contenido de app.yml y modificar este parámetro. Tengo la sensación de que la mayoría de los programas (por ejemplo, Thunderbird) establecen implícitamente el protocolo correcto al seleccionar el puerto 465, ¿entonces tal vez Discourse debería hacerlo? Esto parece ser realmente estándar, también como se destaca aquí:

(enlace a la publicación completa)

Así que realmente defendería la actualización de la sección de esta guía sobre el puerto 465 o hacer que discourse-setup elija automáticamente la mejor configuración.

2 Me gusta

Normalmente no comento sobre nada, ¡pero eso fue realmente útil!
Gracias, el mantenedor de Discourse debería incluir esta configuración en la configuración predeterminada, quiero decir, fue tedioso configurar su software, aún así no tengo nada que criticar, excepto que en un proyecto tan grande alguna información no está disponible rápidamente y alguien debería “profundizar”.
¡OK, funciona para mí!

Se fusionó una publicación en un tema existente: Uso de % en la contraseña SMTP para discourse-setup