¿Conectar a un servidor SMTP en localhost:25 sin autenticación?

Soporte Instalación
1

¿Cuáles son la configuración correcta que se debe pasar a ./discourse-setup para conectarse a un servidor SMTP en localhost:25 sin autenticación?

Me sorprende mucho que esto no sea compatible de forma nativa (OOTB); es la configuración predeterminada en la mayoría de las instalaciones de Linux.

Mi servidor ejecuta Postfix localmente; no es accesible desde Internet. Funciona perfectamente, por ejemplo, al ejecutar el comando mail. Encontré algunas guías no oficiales en Internet que sugieren cambios en /var/discourse/containers/app.yml, y finalmente logré que se instalara e iniciara con la siguiente configuración:

  DISCOURSE_SMTP_ADDRESS: localhost
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse@opensouceecology.org
  DISCOURSE_SMTP_PASSWORD: "none"
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false

Tenga en cuenta que si omito las variables DISCOURSE_SMTP_USER_NAME o DISCOURSE_SMTP_PASSWORD, el script de instalación me reclama indicando que son obligatorias (¿es un error?).

Y ahora, cuando hago clic en el botón “Reenviar correo de activación” en la interfaz web de Discourse, aparece esta entrada en el archivo de registro (/var/discourse/shared/standalone/log/rails/production.log):

Started PUT "/finish-installation/resend-email" for 127.0.0.1 at 2019-11-07 13:15:31 +0000
Processing by FinishInstallationController#resend_email as HTML
  Parameters: {"authenticity_token"=>"SzQCvRWiqdXsBKzOjIB0X7KkvXro7Od6SdP8Qa8vvrskPeNYZNos5ORHJfyDUrHiKShZR/txM6NHuqHHCQCR1w=="}
  Rendering finish_installation/resend_email.html.erb within layouts/finish_installation
  Rendered finish_installation/resend_email.html.erb within layouts/finish_installation (Duration: 0.7ms | Allocations: 103)
  Rendered layouts/_head.html.erb (Duration: 0.5ms | Allocations: 103)
Completed 200 OK in 98ms (Views: 3.0ms | ActiveRecord: 0.0ms | Allocations: 4763)
  Rendering layouts/email_template.html.erb
  Rendered layouts/email_template.html.erb (Duration: 0.5ms | Allocations: 141)
Delivered mail c4ca58ca-345e-46c4-81bc-6d0eac7afa04@discourse.opensourceecology.org (11.3ms)
Job exception: wrong authentication type none

…Pero mi tipo de autenticación es ‘none’. ¿Cuál debería ser la configuración correcta para indicar que no hay autenticación?

EDIT: Además, ¿alguien puede enlazar la documentación que define todas las posibles variables “DISCOURSE_SMTP_*” y todos sus valores válidos?

EDIT2: Esto está resultando ser mucho más difícil de lo que debería. Creo que ‘localhost’ se está resolviendo dentro del contenedor Docker al propio contenedor Docker de Discourse (app), y no al host de Docker que ejecuta mi servidor SMTP Postfix. Esto se complica aún más por mynetworks de Postfix y iptables (que fueron configurados por el script discourse-setup o sus scripts hijos). ¿Cuál es la configuración correcta aquí para que Discourse simplemente utilice el servidor SMTP en el que quiero ejecutar Discourse, sin autenticación SMTP?

1 me gusta
2

Creo que eso no ha sido muy cierto durante unos 20 años.

No puedes usar discourse-setup para situaciones como la tuya porque pocas personas tienen servidores SMTP sin protección por contraseña, incluso detrás de un firewall.

Lo que haría yo es configurar contraseñas SMTP para mi servidor de correo. Realmente no hay mucha desventaja.

Si no quieres hacer eso, creo que en lugar de “none” para la autenticación, podrías usar “” (y lo mismo para la contraseña y el nombre de usuario).

Creo que sí. Podrías probar usando el nombre del contenedor. Creo que necesitas asegurarte de que ambos estén en la misma red Docker.

2 Me gusta
3

En 2019, esta es la configuración predeterminada para Postfix en RHEL/CentOS. Postfix se vincula únicamente a la interfaz de bucle local y descarta todas las solicitudes SMTP que no se originan en 127.0.0.0/8. No se requiere autenticación. No estoy seguro sobre Debian, pero imagino que exim tiene una configuración predeterminada similar.

Algunos temas relevantes en estos foros de otros usuarios que se enfrentaron a este problema:

Parece que no hay ningún tema sobre cómo configurar esto en RHEL/CentOS con los cambios necesarios tanto en Discourse como en Postfix, por lo que lo estoy documentando aquí.

Esto no parece ser posible con el script discourse-setup, pero logré que funcionara.

Primero, tuve que averiguar la dirección IP del host de Docker tal como la ve el contenedor de Docker. Usar 127.0.0.1 no funcionará porque el contenedor de Docker verá 127.0.0.1 como sí mismo. Más bien, necesitamos especificar la dirección IP o el nombre de host del host de Docker que está ejecutando el servidor SMTP de Postfix, y que sea accesible desde el contenedor de Docker (por lo tanto, no la dirección IP pública de tu host de Docker si quieres que tu servidor SMTP no sea accesible desde Internet, por ejemplo).

Extraí la dirección IP relevante del host de Docker (172.17.0.1) de la interfaz docker0 ejecutando lo siguiente en el host de Docker:

[maltfield@osestaging1 ~]$ ip address show docker0
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:80:35:65:a1 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:80ff:fe35:65a1/64 scope link 
       valid_lft forever preferred_lft forever
[maltfield@osestaging1 ~]$

Luego edité el archivo yaml de mi aplicación de Discourse, estableciendo “DISCOURSE_SMTP_ADDRESS” en 172.17.0.1 del ejemplo anterior.

[maltfield@osestaging1 ~]$ cd /var/discourse/
[maltfield@osestaging1 discourse]$ grep SMTP containers/app.yml
  DISCOURSE_SMTP_ADDRESS: 172.17.0.1
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_AUTHENTICATION: none
  DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: none
  DISCOURSE_SMTP_ENABLE_START_TLS: false
[maltfield@osestaging1 discourse]$

Tenga en cuenta que primero intenté usar el nombre de host interno de Docker host.docker.internal para esto, pero aparentemente este nombre de host no está disponible para los usuarios de Docker en Linux

Dado que la configuración predeterminada de Postfix en RHEL/CentOS se vincula únicamente a 127.0.0.1 (lo cual es bueno), necesitará cambiar /etc/postfix/main.cf para que también se vincule a la interfaz docker0 y agregar esa subred al grupo mynetworks para que el tráfico SMTP que provenga de los contenedores de Docker sea aceptado por Postfix.

[maltfield@osestaging1 postfix]$ grep -ir '172.17' /etc/postfix/*
/etc/postfix/main.cf:inet_interfaces = 127.0.0.1, 172.17.0.1
/etc/postfix/main.cf:mynetworks = 127.0.0.0/8, 172.17.0.0/16
[maltfield@osestaging1 postfix]$

Después de esos cambios, reconstruya Discourse y ahora debería poder enviar correos electrónicos a través del Postfix de su host de Docker.

/var/discourse/launcher rebuild app

Aunque esto funciona, tengo algunas preguntas:

  1. ¿Existe alguna otra variable de entorno o nombre de host que ya apunte al host de Docker (172.17.0.1 en este caso)?

Noté que hay una variable de entorno DISCOURSE_HOST_IP “inyectada” por launcher. ¿Es posible establecer esta clave yaml DISCOURSE_SMTP_ADDRESS con el mismo valor que la otra clave yaml con algo como esto?

DISCOURSE_SMTP_ADDRESS: $DISCOURSE_HOST_IP
  1. En general, ¿qué tan duradera es la IP 172.17.0.1 del host de Docker? ¿Es siempre esta IP en los sistemas RHEL/CentOS? ¿Cambiará alguna vez para mí?
3 Me gusta
4

@maltfield Solo quería dar las gracias por las instrucciones.

También tuve el mismo problema en Debian… Supongo que podría crear un usuario de correo separado para Discourse y hacer que se conecte e inicie sesión en site:465, pero conectar al puerto 25 desde dentro me parece más lógico.

Por cierto, en Debian 10 con docker.io de los repositorios, docker0 sigue siendo 172.17.0.1/16.

5

¿Quizás estás malinterpretando lo que dice @maltfield?

Por todo el tiempo que puedo recordar (lo cual se remonta más de 20 años atrás), los sistemas Linux (/ Unix / BSD / Solaris) tienen un servidor SMTP en ejecución que, por defecto, está configurado para retransmitir cualquier cosa recibida desde localhost sin hacer preguntas. Esto libera a cualquier otra aplicación que se ejecute en esa máquina de tener que preocuparse por configurar los ajustes SMTP por sí mismas.

2 Me gusta
6

Sí, la mayoría de los servidores Linux no requieren autenticación para enviar correos (ya sea por defecto o después de la instalación y configuración). Tampoco es necesario si no retransmiten desde ninguna otra parte que no sea la red local. Los scripts de instalación predeterminados de Discourse no funcionarán para la mayoría de los servidores. Están diseñados para un conjunto limitado de soluciones en la nube basadas en Docker.

Puedes leer mis instrucciones completas y exhaustivas para instalar Discourse en un servidor dedicado y físico que ejecute RHEL/CentOS 7 en la wiki de Open Source Ecology. Fíjate en la sección sobre SMTP aquí:

2 Me gusta
7

Bueno, ¡casi siempre me remito a ti en estos asuntos! Supongo que ha pasado un buen número de años desde que ejecuté un servidor SMTP en localhost, así que es muy probable que no sepa de qué estoy hablando.

¡Más evidencia de que tengo la razón! :man_shrugging:

¡Genial!

Pero discourse-setup solo será útil para personas que prácticamente no saben nada sobre administración de sistemas. Si sabes cómo instalar un servidor SMTP, puedes editar un archivo yml.

3 Me gusta
8

Si el host donde se ejecuta el contenedor tiene un nombre accesible mediante DNS, basta con especificarlo así:

DISCOURSE_SMTP_ADDRESS: real.machine.example.com

Postfix seguirá detectando que el origen del correo es local y lo gestionará de esa manera.

1 me gusta
9

Si DISCOURSE_HOSTNAME y DISCOURSE_SMTP_ADDRESS son iguales, ¿causará problemas?

He configurado Postfix y Dovecot en el host de Docker para aceptar solicitudes autenticadas a través de TLS. Tengo certificados válidos para mi servidor, pero con cualquier configuración que intente, no puedo hacer que Discourse envíe correos electrónicos correctamente a Postfix que se ejecuta en el host de Docker.

Si uso el nombre de host (discourse.[mihost].com), no funciona (ni siquiera se conecta). Si uso la dirección IP del host de Docker (172.17.0.1), obtengo

el nombre de host "172.17.0.1" no coincide con el certificado del servidor

Claramente, necesito usar el FQDN que se usó para crear los certificados. Si intento configurar DISCOURSE_SMTP_ENABLE_START_TLS en false, dice que necesito emitir un comando start TLS. Realmente no quiero abrir Postfix sin TLS, así que tampoco veo esto como una opción viable.

Usar un relé SMTP externo tampoco es una opción porque no quiero pagar más solo para asegurarme de que los correos electrónicos no terminen en las carpetas de spam/correo no deseado de las personas.

Tengo que decir que solo tengo una comprensión rudimentaria de la red de Docker, y una comprensión aún menor de la configuración de un servidor SMTP Postfix con Dovecot para la autenticación, pero no soy un completo novato, pero configurar esto de una manera segura/protegida está resultando extremadamente difícil.

@maltfield He leído tu artículo sobre Open Source Ecology, pero no quiero usar sin autenticación a través del puerto 25. La universidad para la que trabajo tiene protocolos muy estrictos sobre el uso de comunicaciones no cifradas y no autenticadas (incluso dentro de una configuración de red local como esta). Les preocupa demasiado que pueda ser abusado por un estudiante descontento.

1 me gusta
10

Así que, me pareció que había algo sospechoso en usar el mismo nombre de host tanto para el servidor Discourse como para el servidor SMTP.

Una investigación más profunda revela que el contenedor de Docker añade la siguiente entrada al archivo hosts:

172.17.0.2	discourse.[mydomain].com discourse

Por lo tanto, cualquier intento de usar el mismo nombre de host para el contenedor en ejecución y el host de Docker hará que todas las solicitudes emitidas desde el contenedor vayan al propio contenedor y no al host de Docker.

¡Qué fiasco! ¿Por qué Discourse no proporciona un servidor SMTP configurado por defecto en el contenedor?
¿O hace que sea más fácil usar Discourse sin Docker?

Dos días de mi vida perdidos por este problema.

11

Al final, acepto el hecho de que no puedo usar TLS para comunicarme con SMTP que se ejecuta en el host de Docker (sin obtener certificados usando un nombre de host diferente). Para que esto funcione finalmente, tuve que asegurarme de que 172.17.0.0/16 se agregara a la variable mynetworks en el archivo main.cf de Postfix:

mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 172.17.0.0/16

Esto permite que Postfix considere que cualquier contenedor de Docker que se ejecute en este servidor es parte de la red.

Otro cambio que tuve que hacer fue asegurarme de que smtpd_sasl_security_options se estableciera en noanonymous para evitar que los “extraños” usaran Postfix como un retransmisor SMTP. Asegúrate de que la opción noplaintext no esté configurada aquí, de lo contrario, Postfix solo permitirá la autenticación mediante TLS.

smtpd_sasl_security_options = noanonymous

Con estas configuraciones, pude especificar los siguientes ajustes en app.yml:

  DISCOURSE_SMTP_ADDRESS: 172.17.0.1                            # IP address of the Docker host (as seen from within this container)
  DISCOURSE_SMTP_PORT: 25
  DISCOURSE_SMTP_USER_NAME: discourse
  DISCOURSE_SMTP_PASSWORD: pa$$word
  DISCOURSE_SMTP_ENABLE_START_TLS: false                         # (optional, default true)
  DISCOURSE_SMTP_DOMAIN: discourse.[mydomian].com                # (required by some providers)
  DISCOURSE_NOTIFICATION_EMAIL: noreply@discourse.[mydomain].com # (address to send notifications from)

También creé una cuenta de usuario local en el host de Docker solo para fines de autenticación SASL.
Con estos cambios, finalmente pude enviar correos desde el contenedor, pero no puedo evitar sentir que esta es una configuración subóptima. Idealmente, debería ser posible usar el nombre de host deseado para el host de Docker y que las solicitudes a discourse.[mydomain].com vayan al lugar correcto.

Ahora necesito configurar SPF y DKIM para que los correos lleguen a las bandejas de entrada de las personas (en lugar de sus carpetas de spam). Realmente espero que algún día este doloroso proceso sea más automatizado. Quizás proporcionar algunas instrucciones sobre cómo configurar Discourse sin usar Docker (para que pueda usarse con cPanel, por ejemplo) o hacer que la configuración de correo sea menos dolorosa proporcionando algún tipo de configuración SMTP predeterminada directamente en el contenedor de Docker.

2 Me gusta
12

Si retrocedieras a principios de la década de 1990, sería como deseas. Las cosas de las que hablas simplemente funcionaban. Pero los spammers han hecho que sea mucho más complicado. El proceso solo se volverá más difícil, por lo que la recomendación es usar algún servicio que se encargue de muchas de las complicaciones por ti.

2 Me gusta
13

¡Me alegra que hayas configurado tu correo electrónico!

Hay algunas actualizaciones en la guía de solución de problemas de correo electrónico desde ayer. Si todavía no estás satisfecho con tu configuración de correo, ¡quizás inténtalo de nuevo!

Se puede resolver usando:

… simplemente la resolución DNS predeterminada del nombre de dominio a la IP.

14

No me malinterpretes. Entiendo la importancia de SPF y DKIM. Simplemente es molesto. Solo desearía que esto pudiera instalarse en nuestros servidores cPanel actuales, donde este tipo de cosas ya están configuradas.

1 me gusta
15

Esto era lo que me faltaba. Ahora funciona con TLS.

También he conseguido que funcione DKIM, así que los correos ya no deberían ser marcados como spam.

2 Me gusta