El receptor de correo no entregará correo a Discourse

Cometí este error y dejé discourse.example.com en el archivo mail-receiver.yml.

Ya lo he corregido, pero parece que mail-receiver no está ‘captando’ los nuevos detalles.
¿Cómo ‘reinicio’ mail-receiver (por ejemplo, ¿cuál es el comando equivalente a ./launcher rebuild app?).

Editar: No leí la publicación anterior con suficiente atención, el comando es ./launcher rebuild mail_receiver.

1 me gusta

Ahora tengo un problema adicional en el que mail-receiver no entrega el correo a Discourse; he intentado buscar ayuda, pero sin éxito.

Registros:

Starting Postfix
Dec 14 03:12:32 forum-mail-receiver postfix/master[1]: daemon started -- version 3.5.6, configuration /etc/postfix
Dec 14 03:15:47 forum-mail-receiver postfix/smtpd[113]: connect from mail-pl1-f169.google.com[209.85.214.169]
Dec 14 03:15:47 forum-mail-receiver postfix/smtpd[113]: 821CB37A659: client=mail-pl1-f169.google.com[209.85.214.169]
Dec 14 03:15:47 forum-mail-receiver postfix/cleanup[120]: 821CB37A659: message-id=<602f2194be912e92b969eacf5eac26e2@frontapp.com>
Dec 14 03:15:47 forum-mail-receiver postfix/qmgr[98]: 821CB37A659: from=<[my personal email address]>, size=4086, nrcpt=1 (queue active)
<23>Dec 14 03:15:47 receive-mail[122]: Recipient: nobody@[my forum URL]
Dec 14 03:15:47 forum-mail-receiver postfix/smtpd[113]: disconnect from mail-pl1-f169.google.com[209.85.214.169] ehlo=1 mail=1 rcpt=1 bdat=1 quit=1 commands=5
<19>Dec 14 03:16:47 receive-mail[122]: Failed to POST the e-mail to [my forum URL]/admin/email/handle_mail: execution expired (Net::OpenTimeout)
<19>Dec 14 03:16:47 receive-mail[122]:   /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
  /usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
  /usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
  /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
  /usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
  /usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
  /usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
  /usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
  /usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
  /usr/local/bin/receive-mail:13:in `<main>'
Dec 14 03:16:47 forum-mail-receiver postfix/pipe[121]: 821CB37A659: to=<nobody@[my forum URL]>, relay=discourse, delay=60, delays=0.17/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 14 03:17:32 forum-mail-receiver postfix/qmgr[98]: 7C67437A663: from=<[my personal email address]>, size=4093, nrcpt=1 (queue active)

¿Alguna idea de qué podría estar causando esto?

El archivo mail-receiver.yml es válido y he comprobado si hay errores tipográficos:

Este es el alcance de mi clave API:

El correo llega a mail-receiver, pero simplemente se queda en la cola de correo:

Alternativamente, ¿hay alguna forma de eliminar por completo el contenedor de mail-receiver y empezar de nuevo?

El problema puede ser que no tengas la clave de API configurada.

Gracias por la respuesta @pfaffman… definitivamente está configurado en mi configuración de mail-receiver.yml. ¿Debería ir entre comillas?

 (Net::OpenTimeout)

Ese es tu problema. El receptor de correo no puede acceder a la URL de tu foro. O bien la tienes mal de alguna manera o hay algún problema de red en docker entre el receptor de correo y tu foro, creo.

¿Cómo puedo solucionar problemas más a fondo?

ping forum.[mydomain].co.nz

desde dentro de mailq muestra:

64 bytes from [ip].vultrusercontent.com ([ip]): icmp_seq=1 ttl=64 time=0.113 ms
64 bytes from [ip].vultrusercontent.com ([ip]): icmp_seq=2 ttl=64 time=0.074 ms
64 bytes from [ip].vultrusercontent.com ([ip]): icmp_seq=3 ttl=64 time=0.069 ms

y así sucesivamente, mostrando que la conexión es exitosa.
forum.[mydomain].co.nz es donde está alojado el foro, y esta misma URL se utiliza en MAIL_DOMAIN y DISCOURSE_MAIL_ENDPOINT.

Mirando más de cerca la configuración de mail-receiver.yml, ¿me faltan comillas o https:// en algún lugar donde deberían estar?

## esta es la plantilla del contenedor receptor de correo
##
## Después de realizar cambios en este archivo, DEBE reconstruir
## /var/discourse/launcher rebuild mail-receiver
##
## ¡TENGA MUCHO CUIDADO AL EDITAR!
## ¡LOS ARCHIVOS YAML SON SÚPER SÚPER SENSIBLES A ERRORES DE ESPACIO EN BLANCO O ALINEACIÓN!
## visite http://www.yamllint.com/ para validar este archivo según sea necesario


base_image: discourse/mail-receiver:release
update_pups: false

expose:
  - "25:25"   # SMTP

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8


  ## A dónde se debe enviar el correo a su foro. En general, está perfectamente bien
  ## usar el mismo dominio que el foro aquí.
  MAIL_DOMAIN: forum.[domain].co.nz
# descomente estas (¡y el volumen de abajo!) para admitir TLS
#  POSTCONF_smtpd_tls_key_file:  /letsencrypt/discourse.example.com/discourse.example.com.key
#  POSTCONF_smtpd_tls_cert_file:  /letsencrypt/discourse.example.com/fullchain.cer
#  POSTCONF_smtpd_tls_security_level: may


  ## La URL del punto final de procesamiento de correo de su foro de Discourse.
  ## Esta es simplemente la URL base de su foro, con `/admin/email/handle_mail`
  ## añadido. Tenga cuidado si está ejecutando una configuración de subcarpeta; en ese caso,
  ## ¡la URL debe incluir la subcarpeta!
  DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'

  ## La clave API maestra de su foro de Discourse. Puede obtenerla de
  ## la pestaña "API" de su panel de administración.
  DISCOURSE_API_KEY: 639[rest of API key]884ef

  ## El nombre de usuario a utilizar para procesar el correo entrante. A menos que haya
  ## renombrado el usuario `system`, debería dejarlo como está.
  DISCOURSE_API_USERNAME: system

volumes:
  - volume:
      host: /var/discourse/shared/mail-receiver/postfix-spool
      guest: /var/spool/postfix
# descomente para admitir TLS
#  - volume:
#      host: /var/discourse/shared/standalone/letsencrypt
#      guest: /letsencrypt

¿Estás ejecutando el ping dentro del contenedor, es decir, después de ejecutar primero ./launcher enter mail-receiver?

También vale la pena señalar que ping (típicamente ICMP) es diferente de conectarse a http/https (TCP) y puede comportarse de manera diferente dependiendo de muchos factores en la configuración de red.

Intentaría usar curl después de entrar en el contenedor para ver si puede conectarse a tu foro a través de https, por ejemplo:

cd /var/discourse
./launcher enter mail-receiver
curl -v https://forum.[domain].co.nz

Si funciona, imprimirá un montón de HTML. Si no, mostrará algún error y -v hará que imprima mucha información a lo largo del camino que podría ayudar a revelar por qué falló.

Si falla, también vale la pena intentar ejecutar el mismo comando curl fuera del contenedor para identificar si es específico del contenedor o del sistema anfitrión en general.

3 Me gusta

Gracias @Simon_Manning, ¡tu ayuda es muy apreciada! No sabía que las conexiones a través de ping no son necesariamente lo mismo que las conexiones a través de curl.

Estaba ejecutando ping dentro del contenedor y funcionó.

Seguí tus instrucciones y ejecuté curl dentro del contenedor, y falló:

root@forum:/var/discourse# ./launcher enter mail-receiver
x86_64 arch detected.
WARNING: containers/mail-receiver.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/mail-receiver.yml
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)
root@forum-mail-receiver:/# curl -v https://forum.[domain].co.nz
*   Trying [IPv4 address]:443...
*   Trying [IPv6 address]:443...
* Immediate connect fail for [IPv6 address]: Cannot assign requested address
* connect to [IPv4 address] port 443 failed: Connection timed out
* Failed to connect to forum.[domain].co.nz port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to forum.[domain].co.nz port 443: Connection timed out

Luego ejecuté exit y luego curl de nuevo, y obtuve:

root@forum:/var/discourse# curl -v https://forum.[domain].co.nz
*   Trying 127.0.1.1:443...
* Connected to forum.[domain].co.nz (127.0.1.1) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: /etc/ssl/certs
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Certificate Status (22):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...and so on.

Parece que es específico del contenedor y no del sistema anfitrión. ¿Alguna idea?

¡También he abierto un ticket de soporte con Vultr (proveedor de VPS para esta instancia) para ver si es un problema de su lado!

Docker crea redes virtuales para los contenedores y, en ausencia de especificar una, los contenedores usarán la red predeterminada. Esta red predeterminada no permite la comunicación entre contenedores.

Normalmente, esto está bien para mail-receiver porque tu contenedor de Discourse tendrá el puerto 443 expuesto fuera de esa red y, cuando mail-receiver intente conectarse a 1.2.3.4, saldrá de la red de Docker. El sistema host (o alguna red más externa) se dará cuenta de que solo necesita volver a entrar y terminará entrando al contenedor de Discourse desde el exterior.

Se me ocurren dos posibilidades. Una es que mail-receiver sea de alguna manera consciente de la IP del contenedor de Discourse al buscar el nombre de dominio y, por lo tanto, se bloquee una conexión intra-contenedor. Creo que esto es poco probable.

La otra es que un firewall en el sistema host esté bloqueando las conexiones que salen de un contenedor y entran en otro. Vultr puede usar reglas de firewall predeterminadas que causen esto o también recuerdo vagamente que Docker instala algunas reglas en UFW de forma predeterminada, por lo que podría estar relacionado si se usa eso.

2 Me gusta

No puedes usar https porque no descomentaste esto:

Eso solo se aplica al soporte TLS en el lado del servidor de correo, es decir, para que otros servidores de correo puedan entregar correos electrónicos a mail-receiver a través de TLS.

Vale la pena hacerlo ya que el contenedor de Discourse evidentemente tiene un certificado, pero no debería afectar la conexión de mail-receiver a Discourse. Potencialmente, la reconstrucción podría hacerlo si corrige algo en la red del contenedor.

Gracias, he descomentado esas líneas y la línea del volumen.

Mi archivo mail-receiver.yml ahora se ve así:

root@forum:/var/discourse# cat containers/mail-receiver.yml
## este es el contenedor de plantilla del receptor de correo entrante
##
## Después de realizar cambios en este archivo, DEBE reconstruir
## /var/discourse/launcher rebuild mail-receiver
##
## ¡TENGA MUCHO CUIDADO AL EDITAR!
## ¡LOS ARCHIVOS YAML SON SÚPER SÚPER SENSIBLES A ERRORES DE ESPACIOS O ALINEACIÓN!
## visite http://www.yamllint.com/ para validar este archivo según sea necesario

base_image: discourse/mail-receiver:release
update_pups: false

expose:
  - "25:25"   # SMTP

env:
  LC_ALL: en_US.UTF-8
  LANG: en_US.UTF-8
  LANGUAGE: en_US.UTF-8

  ## A dónde se debe enviar el correo a su foro. En general, está perfectamente bien
  ## usar el mismo dominio que el foro mismo aquí.
  MAIL_DOMAIN: forum.[domain].co.nz
# descomente estas (¡y el volumen de abajo!) para admitir TLS
  POSTCONF_smtpd_tls_key_file:  /letsencrypt/forum.[domain].co.nz/forum.[domain].co.nz.key
  POSTCONF_smtpd_tls_cert_file:  /letsencrypt/forum.[domain].co.nz/fullchain.cer
  POSTCONF_smtpd_tls_security_level: may


  ## La URL del punto final de procesamiento de correo de su foro de Discourse.
  ## Esta es simplemente la URL base de su foro, con `/admin/email/handle_mail`
  ## añadido. Tenga cuidado si está ejecutando una configuración de subcarpeta; en ese caso,
  ## ¡la URL debe incluir la subcarpeta!
  DISCOURSE_MAIL_ENDPOINT: 'https://forum.[domain].co.nz/admin/email/handle_mail'

  ## La clave API maestra de su foro de Discourse. Puede obtenerla de
  ## la pestaña "API" de su panel de administración.
  DISCOURSE_API_KEY: '074[resto de la clave API - sí, generé una nueva limitada al usuario del sistema]d98'

  ## El nombre de usuario a utilizar para procesar el correo entrante. A menos que haya
  ## renombrado al usuario `system`, debería dejar esto como está.
  DISCOURSE_API_USERNAME: system

volumes:
  - volume:
      host: /var/discourse/shared/mail-receiver/postfix-spool
      guest: /var/spool/postfix
# descomentar para admitir TLS
  - volume:
      host: /var/discourse/shared/standalone/letsencrypt
      guest: /letsencrypt

Cuando envío un nuevo correo electrónico y ejecuto ./launcher logs mail-receiver, esto es lo que veo:

Dec 21 22:41:21 forum-mail-receiver postfix/smtpd[132]: connect from mail-pj1-f54.google.com[209.85.216.54]
Dec 21 22:41:23 forum-mail-receiver postfix/smtpd[132]: 16DAC379E42: client=mail-pj1-f54.google.com[209.85.216.54]
Dec 21 22:41:23 forum-mail-receiver postfix/cleanup[139]: 16DAC379E42: message-id=<94fc2bef18b410ae8b121c6af2da2df4@frontapp.com>
Dec 21 22:41:23 forum-mail-receiver postfix/qmgr[100]: 16DAC379E42: from=<[mi dirección de correo electrónico]>, size=5585, nrcpt=1 (queue active)
<23>Dec 21 22:41:23 receive-mail[141]: Recipient: nobody@forum.[domain].co.nzDec 21 22:41:50 forum-mail-receiver postfix/smtpd[143]: connect from mail-oa1-f50.google.com[209.85.160.50]
Dec 21 22:41:52 forum-mail-receiver postfix/smtpd[143]: 2E445379E48: client=mail-oa1-f50.google.com[209.85.160.50]
Dec 21 22:41:52 forum-mail-receiver postfix/cleanup[139]: 2E445379E48: message-id=<6b2f9d646dc46f4fec4af006de01d3ae@frontapp.com>
Dec 21 22:41:52 forum-mail-receiver postfix/qmgr[100]: 2E445379E48: from=<[mi dirección de correo electrónico]>, size=4100, nrcpt=1 (queue active)
<23>Dec 21 22:41:52 receive-mail[147]: Recipient: nobody@forum.[domain].co.nzDec 21 22:41:53 forum-mail-receiver postfix/smtpd[132]: disconnect from mail-pj1-f54.google.com[209.85.216.54] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
Dec 21 22:41:58 forum-mail-receiver postfix/qmgr[100]: 1194937A670: from=<double-bounce@forum-mail-receiver.localdomain>, size=942, nrcpt=1 (queue active)
Dec 21 22:41:58 forum-mail-receiver postfix/smtp[149]: fatal: unknown service: smtp/tcp
Dec 21 22:41:59 forum-mail-receiver postfix/qmgr[100]: warning: private/smtp socket: malformed response
Dec 21 22:41:59 forum-mail-receiver postfix/qmgr[100]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Dec 21 22:41:59 forum-mail-receiver postfix/master[1]: warning: process /usr/lib/postfix/sbin/smtp pid 149 exit status 1
Dec 21 22:41:59 forum-mail-receiver postfix/master[1]: warning: /usr/lib/postfix/sbin/smtp: bad command startup -- throttling
Dec 21 22:41:59 forum-mail-receiver postfix/error[150]: 1194937A670: to=<postmaster@forum-mail-receiver.localdomain>, orig_to=<postmaster>, relay=none, delay=1192, delays=1191/1/0/0.01, dsn=4.3.0, status=deferred (unknown mail transport error)
<19>Dec 21 22:42:23 receive-mail[141]: Failed to POST the e-mail to https://forum.sobercheck.co.nz/admin/email/handle_mail: execution expired (Net::OpenTimeout)<19>Dec 21 22:42:23 receive-mail[141]:   /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
  /usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
  /usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
  /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
  /usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
  /usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
  /usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
  /usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
  /usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
  /usr/local/bin/receive-mail:13:in `<main>'Dec 21 22:42:23 forum-mail-receiver postfix/pipe[140]: 16DAC379E42: to=<nobody@forum.[domain].co.nz>, relay=discourse, delay=60, delays=0.23/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 21 22:42:25 forum-mail-receiver postfix/smtpd[143]: disconnect from mail-oa1-f50.google.com[209.85.160.50] ehlo=2 starttls=1 mail=1 rcpt=1 bdat=1 quit=1 commands=7
<19>Dec 21 22:42:52 receive-mail[147]: Failed to POST the e-mail to https://forum.[domain].co.nz/admin/email/handle_mail: execution expired (Net::OpenTimeout)<19>Dec 21 22:42:52 receive-mail[147]:   /usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize'
  /usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
  /usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
  /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
  /usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
  /usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
  /usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
  /usr/lib/ruby/2.7.0/net/http.rb:1483:in `request'
  /usr/local/lib/site_ruby/mail_receiver/discourse_mail_receiver.rb:43:in `process'
  /usr/local/bin/receive-mail:13:in `<main>'Dec 21 22:42:52 forum-mail-receiver postfix/pipe[146]: 2E445379E48: to=<nobody@forum.[domain].co.nz>, relay=discourse, delay=60, delays=0.15/0.01/0/60, dsn=4.3.0, status=deferred (temporary failure)
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max connection rate 1/60s for (smtp:209.85.216.54) at Dec 21 22:41:21
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max connection count 1 for (smtp:209.85.216.54) at Dec 21 22:41:21
Dec 21 22:45:45 forum-mail-receiver postfix/anvil[135]: statistics: max cache size 2 at Dec 21 22:41:50

Estoy realmente atascado ahora, ¿alguien tiene alguna idea de qué podría estar causando esto? :grinning_face_with_smiling_eyes:

¡Doh! Sí. Confundí TLS con https.

Esto todavía no funciona en absoluto, no se están enviando correos electrónicos de mail-receiver a Discourse.

¿Puedo ‘deshacer’ mail-receiver para que vuelva al principio (restablecerlo por completo) y empezar de nuevo, con la esperanza de que funcione?
¿Cómo puedo hacer esto?

Puedes simplemente editar el archivo y reconstruir el contenedor de correo.

¡Gracias por el consejo sobre el firewall! Yo también tuve problemas similares a los de @MathiasFoster, con el contenedor mail-receiver que no podía acceder al sitio del foro en el contenedor app. Un poco desconcertante al principio, ya que los contenedores pueden escuchar en el mundo exterior sin problemas.

También estoy usando Vultr como mi proveedor de VPS con su imagen del sistema operativo Ubuntu. Alguna combinación de los valores predeterminados de la imagen del sistema operativo más Docker parece bloquear la comunicación entre contenedores.

De todos modos, en mi caso, fue suficiente permitir HTTPS en el host:

$ ufw allow https

Después de eso, el mail-receiver pudo entregar el correo como se esperaba.

1 me gusta