¿Usar servidor de correo local/sendmail para correos salientes?

[MichaIng]

Configuramos nuestro propio servidor de correo electrónico y me preguntaba cómo usarlo mejor con el contenedor Docker de Discourse.

Por supuesto, puedo configurar los detalles y credenciales de nuestro SMTP, pero parece una sobrecarga innecesaria, ya que el servidor SMTP se ejecuta en la misma máquina.

sendmail funciona, pero Discourse está en el contenedor, por lo tanto, no tiene acceso a sendmail en su host.

Buscar algo aquí en el foro da un ejemplo donde se usó DISCOURSE_SMTP_DOMAIN sin credenciales, donde hacer lo mismo con swaks dentro del contenedor funciona: How to get Discourse to work with Postfix - #18 by sonmicrosystems
Supongo que en ese caso, sigue siendo una presentación SMTP normal en el puerto predeterminado, y Postfix la acepta sin autenticación, ya que la solicitud proviene de localhost.

¿Alguien conoce otro método? Veo que la biblioteca Ruby utilizada generalmente admite todo: GitHub - discourse/mail: A Really Ruby Mail Library
En la configuración de Discourse, lo que me llamó la atención es un campo Delivery method:

No puedo cambiar esta configuración en la GUI, supongo porque el YAML del contenedor las impone a través de DISCOURSE_SMTP_ADDRESS, etc. Pero no encuentro una variable para el método de entrega.

Quizás alguien conozca otra forma, y hasta entonces, estoy configurando la autenticación normal del puerto de presentación SMTP. Gracias por DISCOURSE_SMTP_FORCE_TLS, agregado más recientemente, pero aún no es parte de ninguna muestra (debería serlo). No tengo la intención de permitir STARTTLS, sino solo TLS implícito/inmediato.

[itsbhanusharma (Bhanu Sharma)]

@MichaIng

siento que es una sobrecarga innecesaria, ya que el servidor SMTP se ejecuta en la misma máquina.

¿Sobrecarga innecesaria cómo? Tienes que enviar los datos de Discourse al servidor SMTP de alguna manera, ¿no?

PD: si es otro contenedor, en teoría podrías usar la red bridge y usar el nombre del contenedor smtp en lugar del nombre de host si es eso lo que buscas, pero no te dará ninguna ventaja de rendimiento.

[MichaIng]

@itsbhanusharma

¿Excesiva carga innecesaria? ¿Tienes que enviar los datos de Discourse al servidor SMTP de alguna manera? ¿No?

Hay dos formas de enviar correos electrónicos a través de un servidor SMTP local:

1. Conectarse y autenticarse en el puerto de envío, como 587 con STARTTLS o 465 con TLS implícito/inmediato => solicitud de red, comprobaciones y restricciones aplicadas a través de smtpd
2. Usar sendmail o similar, que invoca el comando local pickup (en el caso de Postfix), sin realizar ninguna conexión de red y omitiendo todas las comprobaciones y restricciones configuradas para el servicio de envío smtpd.

Este último es más simple y rápido, implementado en sistemas y frameworks de tiempo de ejecución comunes, como PHP mailer y esta biblioteca de correo Ruby utilizada por Discourse. Y la autenticación se omite, no es necesario almacenar credenciales en texto plano en ningún lugar. O en otras palabras: el servidor SMTP no se utiliza en absoluto en este caso, sino solo el cliente SMTP.

Quiero decir, sí, la conexión al puerto de envío no debería tener un impacto significativo en la carga del servidor, en comparación con lo que hace Discourse de lo contrario. Este último punto se puede resolver con, por ejemplo, la regla smtpd_recipient_restrictions=permit_mynetworks,permit_sasl_authenticated,reject en el puerto de envío, para permitir envíos desde IPs de loopback (por defecto, configuración de mynetworks) antes de realizar cualquier autenticación. Si la solicitud del contenedor se ve con otra IP, se puede agregar a mynetworks. Supongo que así es como funcionó en el caso del tema que enlacé antes.

Veremos la próxima vez que actualicemos/reconstruyamos nuestro Discourse, cuando se apliquen los ajustes SMTP modificados. Informaré cómo funciona.

Pero aún así sería interesante saber si hay otras formas y qué significa esta configuración de “Método de entrega”.

@itsbhanusharma

Ps: si es otro contenedor, en teoría podrías usar la red de puente y usar el nombre del contenedor smtp en lugar del nombre del host si eso es lo que buscas, pero no te dará ninguna ventaja de rendimiento.

Postfix se ejecuta en el host, no dentro de un contenedor, pero no haría mucha diferencia, ya que sigue siendo una autenticación basada en red.

Sí, un pensamiento posterior, tiene sentido que sendmail, etc. del host/otro contenedor no puedan funcionar dentro de un contenedor, ya que requiere acceso directo a vastas partes de los ejecutables, bibliotecas y configuraciones de Postfix, supongo. A menos que haya una especie de socket mágico que se pueda montar en el contenedor o algo así .

[itsbhanusharma (Bhanu Sharma)]

Ha pasado un tiempo desde que me adentré tanto en la microgestión de sendmail. Tengo mailcow stack en una VM y Discourse en otra. No sé si alguna vez valdrá la pena profundizar tanto, aparte de por pura diversión.

Te deseo lo mejor en tus aventuras, informa de lo que aprendas.

[MichaIng]

@itsbhanusharma

No sé si alguna vez valdrá la pena profundizar tanto, más allá de la diversión.

Probablemente no . Pero soy perfeccionista en ciertos contextos y disfruto profundizando y aprendiendo todos los detalles. Me llevó varias tardes configurar Dovecot, Postfix, rspamd, dkimpy-milter, PostSRSd,… paso a paso, aprendiendo sobre casi todas las configuraciones disponibles, por qué los valores predeterminados son así, si y por qué podríamos querer algo diferente, etc. Pero bueno, ahora parece que entiendo la mayoría de las cosas mejor que la mayoría de los autores de guías arbitrarias de servidores de correo .

[tobiaseigen]

Muevo este tema a Installation > Hosting. No recomendamos intentar alojar su propio servidor de correo, como saben si leyeron las instrucciones de instalación oficiales. ¡El correo electrónico es difícil!

[MichaIng]

No estoy seguro de qué tiene que ver Discourse con si el sistema puede alojar o no un servidor de correo electrónico adicional. Aparte del hecho de que esto teóricamente abre otra forma de enviar correos electrónicos, por supuesto.

Para recibir correos electrónicos (otro tema), sin embargo, tiene un efecto, ya que uno no puede alojar el contenedor del receptor de correo electrónico entonces, al menos no para escuchar directamente en el puerto 25. Pero usar la API del receptor de correo electrónico de Discourse directamente resultó ser solo 2-3 líneas en la configuración de Postfix: Is there a way to only IMAP polling for incoming emails - #2 by MichaIng

Pero estoy de acuerdo, configurar el servidor de correo electrónico correctamente no fue exactamente una tarea fácil, como se mencionó anteriormente. Pero súper interesante de aprender .

[tobiaseigen]

¡Sí! Es desafiante e interesante, sin duda. ¡He pasado por mis propias aventuras instalando todo tipo de servicios e intentando ejecutarlos yo mismo, en una vida anterior!

Me alegra que actualices este tema con tus aprendizajes en beneficio de intrépidos viajeros futuros, incluyéndote a ti. Pero ten en cuenta que la categoría Support es para instalaciones compatibles, el núcleo de Discourse y plugins y componentes oficiales.

[nineb]

@MichaIng

Dovecot, Postfix

¿Qué? Dovecot es bueno. ¿Por qué entonces Postfix? ¿Por qué no Dovecot Exim?

[MichaIng]

¿Qué le pasa a Postfix? Formaba parte de la primera guía de configuración de servidores de correo que leí, y sus opciones de filtro internas para reducir el spam y el acceso de bots al principio del proceso parecían un buen argumento.

Bueno, algo fuera de tema, en relación con el uso de sendmail/pickup de Discourse.

Marco esto como resuelto/respondido. Tiene sentido que el contenedor de Discourse no pueda acceder al sendmail del host, sin importar el servidor. Por lo tanto, necesita usar la sumisión SMTP, para la cual se puede autenticar, por ejemplo, a través del rango de IP del contenedor de Docker en Postfix, omitiendo la autenticación passdb/userdb en Dovecot.