If you have a mail receiver container which requires customised Postfix configuration, this is the topic for you. Herein are described the steps required to set Postfix main.cf configuration variables to whatever your heart desires.
Postfix configuration variables can be set via the container environment. Any environment variable starting with POSTCONF_ will set a Postfix configuration variable named for the rest of the environment variable to the value of the environment variable. For example, if you set the environment variable POSTCONF_always_bcc to bob@example.com, then Postfix will be configured with always_bcc = bob@example.com, which will send a copy of all incoming mail to Bob. Poor Bob.
Procedure
Figure out what configuration variables you want to set, and what values to set them to. This may be done by reading the fine manual, or through recommendations in other Discourse documentation, or otherwise.
Connect to your Discourse server via SSH, grab some root privileges, and head over to where all the discourse-docker configuration lives:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Open up containers/mail-receiver.yml in your text editor of choice, and swing down to the env: section of the file. Somewhere in there, add entries for the variables you want to add, being careful to not modify anything else, and maintaining appropriate indenting. For example, if we were adding our always_bcc setting, the file might look a bit like this:
Once you’re happy with what you’ve added, save and exit your editor.
To load the configuration, you simply have to restart the mail-receiver container (a rebuild is not required):
./launcher restart mail-receiver
After a brief spasm, the container should be running again.
Test your changes. Ensure both that what you wanted to have happen has, indeed, happened, and also that nothing you didn’t expect to change hasn’t.
Addendum: adding files to the mail-receiver container
Many Postfix configuration parameters require access to “database files”, which provide key/value information which Postfix uses to make decisions about what do with mail. If you see that a configuration parameter accepts a filename that looks like hash:/some/file, you’ve found a use for database files.
The thing is, Postfix running inside the container needs to be able to get at those files while it’s running, which means you need to either copy those files into the container, or (preferably) put those files into a directory on the host, and then mount that directory as a volume inside the container. These instructions describe the second method.
Once you have completed this procedure, any file you place into /var/discourse/shared/mail-receiver/etc will immediately become visible at /etc/postfix/shared inside the container, and any changes you make to those files will be immediately visible to Postfix.
Here’s how to make it happen.
If you’re not still logged in as root to your Discourse server, do so again:
ssh ubuntu@192.0.2.42
sudo -i
cd /var/discourse
Open up containers/mail-receiver.yml in your text editor of choice, and this time head for the volume: section. Underneath the existing definition for the /var/spool/postfix directory, add another one, so that your volume section looks like this:
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.
