Si tienes un contenedor de receptor de correo que requiere una configuración personalizada de Postfix, este es el tema adecuado para ti. Aquí se describen los pasos necesarios para establecer las variables de configuración main.cf de Postfix según tus necesidades.
Las variables de configuración de Postfix pueden establecerse mediante las variables de entorno del contenedor. Cualquier variable de entorno que comience con POSTCONF_ establecerá una variable de configuración de Postfix cuyo nombre será el resto de la variable de entorno, con el valor de dicha variable de entorno. Por ejemplo, si estableces la variable de entorno POSTCONF_always_bcc en bob@example.com, Postfix se configurará con always_bcc = bob@example.com, lo que enviará una copia de todo el correo entrante a Bob. Pobre Bob.
Procedimiento
Determina qué variables de configuración deseas establecer y qué valores asignarles. Esto puede hacerse consultando el manual oficial, siguiendo recomendaciones en otra documentación de Discourse o mediante otros medios.
Conéctate a tu servidor Discourse mediante SSH, obtén privilegios de root y dirígete al directorio donde reside toda la configuración de discourse-docker:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Abre containers/mail-receiver.yml en tu editor de texto preferido y baja hasta la sección env: del archivo. En algún lugar de esa sección, agrega entradas para las variables que deseas añadir, teniendo cuidado de no modificar nada más y manteniendo la indentación adecuada. Por ejemplo, si estuviéramos agregando nuestra configuración always_bcc, el archivo podría verse más o menos así:
Una vez que estés satisfecho con lo que has agregado, guarda y sal del editor.
Para cargar la configuración, simplemente debes reiniciar el contenedor mail-receiver (no es necesario hacer un rebuild):
./launcher restart mail-receiver
Tras un breve momento de reinicio, el contenedor debería estar funcionando nuevamente.
Prueba tus cambios. Asegúrate de que lo que esperabas que ocurriera, de hecho, haya ocurrido, y también de que nada que no esperabas cambiar haya sido modificado.
Apéndice: agregar archivos al contenedor mail-receiver
Muchos parámetros de configuración de Postfix requieren acceso a “archivos de base de datos”, que proporcionan información clave/valor que Postfix utiliza para tomar decisiones sobre qué hacer con el correo. Si ves que un parámetro de configuración acepta un nombre de archivo que se parece a hash:/some/file, has encontrado un caso de uso para archivos de base de datos.
El problema es que Postfix, al ejecutarse dentro del contenedor, necesita poder acceder a esos archivos mientras está en funcionamiento. Esto significa que debes copiar esos archivos dentro del contenedor o (preferiblemente) colocarlos en un directorio del host y luego montar ese directorio como un volumen dentro del contenedor. Estas instrucciones describen el segundo método.
Una vez completado este procedimiento, cualquier archivo que coloques en /var/discourse/shared/mail-receiver/etc será inmediatamente visible en /etc/postfix/shared dentro del contenedor, y cualquier cambio que realices en esos archivos será inmediatamente visible para Postfix.
Así es como hacerlo.
Si aún no has iniciado sesión como root en tu servidor Discourse, hazlo nuevamente:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Abre containers/mail-receiver.yml en tu editor de texto preferido y, esta vez, dirígete a la sección volume:. Debajo de la definición existente para el directorio /var/spool/postfix, agrega otra, de modo que tu sección volume se vea así:
Matt, do you think that could be possible to enable accounts like admin@domain or info@domain from this Postfix configuration?
I only need to have a couple of addresses for incoming e-mail and I have it working with Discourse but I can’t set accounts (their seem to be blocked by default even though messages are processed).
Acabo de configurar un servicio de prueba de Discourse usando Digital Ocean y Mailgun para el correo electrónico saliente. Tengo un dominio registrado con un registro MX adecuado que apunta a la dirección IP de Digital Ocean. El correo electrónico saliente y entrante funciona correctamente con Discourse. Las respuestas a los temas generan correos electrónicos salientes a quienes tienen notificaciones configuradas y los usuarios de prueba pueden responder a estos correos electrónicos y las publicaciones aparecen en Discourse. Todo bien hasta ahora.
Intenté agregar la opción POSTCONF_always_bcc: como se mencionó anteriormente, pero no parece funcionar. Sospecho que la parte ‘mail-receiver’ de Discourse no puede enviar el correo electrónico correctamente a través de Mailgun, aunque la parte ‘app’ conoce cómo hacerlo. app.yml tiene el nombre de usuario y la contraseña del servidor Mailgun, pero no he visto ningún ejemplo de cómo poner esta información en el archivo de configuración de mail-receiver.
Sé que la opción always_bcc se está leyendo y actuando, ya que si escribo:
./launcher enter mail-receiver
luego ejecuto
mailq
Puedo ver un mensaje de prueba que envié, que está en la cola intentando ser entregado. En la columna “-Sender/Recipient-------” tiene la dirección desde la que provino mi mensaje de prueba, las palabras “(unknown mail transport error)” y luego la dirección de correo electrónico que tenía en la configuración always_bcc.
Esperaba poder filtrar los mensajes entrantes de alguna manera para que si se enviaba un mensaje a postmaster@mydomain o admin@mydomain, se reenviara a través de Internet público, a través de Mailgun, a mi dirección de Gmail y no se enviara a Discourse para su procesamiento. Esto puede ser lo que el usuario @satonotdead estaba tratando de hacer.
¡Cualquier indicio será apreciado sobre cómo hacer esto!
Hmm. Sí, primero necesitarás configurar el receptor de correo (en lugar de mailgun) para que tenga algún medio de entrega de correo, ya que no conoce las credenciales o el mecanismo de transporte en app.yml. Creo que necesitarás agregar una configuración más completa, como se insinúa en la siguiente sección sobre el montaje de volúmenes, cuyos detalles escapan al alcance de este documento.
La solución simple para “cómo lidiar con los correos electrónicos de postmaster y admin” es crear un grupo para cada uno y agregar a quien quieras que reciba esos correos a ese grupo, y ellos podrán manejarlos como mensajes de grupo.
¿Te refieres a ‘mail-receiver’ en lugar de Mailgun? ¿Como enseñar a ‘mail-receiver’ a hablar con Mailgun a través de Internet y pasar las credenciales correctamente para pedirle que realice las entregas reales?
Bueno, sí, eso, o de alguna otra manera, configurar el ‘mail-receiver’ (es decir, Postfix) para entregar el correo de alguna manera. Soy de la opinión de que si sabes cómo hacerlo, podrías hacerlo en lugar de usar el ‘mail-receiver’.
Otra solución sería tener algún proceso <mail thing> que procese el correo para domain y reenvíe el resto al ‘mail-receiver’, quizás bajo algún otro MX.
Después de pasar esta noche probando numerosas combinaciones, he logrado instalar postfix fuera de los contenedores en los que se ejecuta Discourse y puedo enviar correos electrónicos a través de Mailgun de esa manera desde la línea de comandos, por lo que he configurado postfix para usar Mailgun con éxito. Todavía no encuentro la manera de introducir la configuración en el contenedor del receptor de correo que haga que el reenvío funcione a través de Mailgun. Estoy seguro de que debe haber una forma (¡sencilla!). No parece que encuentre ningún registro para saber por qué los mensajes se quedan atascados en la cola de correo. Los contenedores no existían la última vez que usé Linux (hace varios años). ¿Hay alguna forma de activar el registro para poder ver qué comunicación intenta realizar postfix y así poder averiguar dónde está el problema? Conceptualmente, me gustaría que admin@midominio, una vez que haya entrado, saliera directamente a mi cuenta personal de Gmail a través de Mailgun, mientras que category1@midominio y category2@midominio, etc., se enviaran localmente a Discourse para usarlos para crear publicaciones.
¿Podemos usar el “mail-receiver” fuera de los contenedores de Discourse en otro VPS o centro de datos?
La idea es cambiar la dirección IP de Discourse para una mayor privacidad y usar un “mail-receiver” externo que funcione/se autentique con el foro de Discourse.
No se requiere nada especial para configurar el receptor de correo en ningún servidor, siempre y cuando tenga docker y acceso a los puertos necesarios.
Normalmente, el banner EHLO debería coincidir con MAIL_DOMAIN, que a su vez debería coincidir con el puntero DNS inverso (registro PTR). Por lo tanto, si mi mail-receiver se ejecuta en discourse.example, entonces POSTCONF_myhostname debería ser discourse.example.
¿Cuál es la forma correcta de configurar el banner EHLO?
Mi primera intuición fue intentar establecer HOSTNAME en mail-receiver.yml para que reemplazara el host-mail-receiver.localdomain original en /etc/postfix/mail-receiver-environment.json. Pero esto no cambia /etc/hostname ni myhostname en la configuración de Postfix.
Me tienta usar POSTCONF_myhostname, pero temo que tendrá efectos secundarios no deseados, ya que $myhostname se usa en varios lugares y entonces ya no coincidiría con /etc/hostname.
Hay una configuración que Discourse-setup solicita. No recuerdo su nombre y es difícil de encontrar en mi teléfono. Puedes mirar el código fuente o ejecutarlo.
La configuración de Postfix smtp_helo_name cambia el nombre especificado en el comando HELO (o EHLO), pero esa es una configuración de entrega saliente, mientras que el banner SMTP se envía al recibir correo. El nombre de host predeterminado especificado en ese se toma de myhostname, pero puede modificar el banner para mostrar algo diferente con la configuración smtpd_banner.
No estoy seguro de si esto ayudará a otros, estaba teniendo un problema similar y esto me ayudó a darme cuenta de que por alguna razón había revocado la clave de la API. Una vez que deshice la revocación, el correo entrante volvió a funcionar.
Así que gracias por ayudarme a darme cuenta de que estaba relacionado con la clave de la API
¿Ha cambiado algo desde que se escribió esto? Acabo de descubrir que añadir un valor POSTCONF_smtpd_banner bajo env: no fue captado en absoluto por múltiples reinicios. Tuve que reconstruir (./launcher rebuild mail-receiver) para que surtiera efecto.
Acabo de completar una migración de dominio (según Change the domain name or rename your Discourse) que fue bien. Sin embargo, estoy usando el contenedor mail-receiver con registros MX para el correo entrante a un par de categorías…
Hasta donde puedo ver, la configuración predeterminada del contenedor codifica la dirección del dominio entrante y la ruta a los certificados LetsEncrypt. ¿Es posible permitir dos dominios, ya sea en la configuración o a través de estas opciones avanzadas?
