Reply by Email autoalojado dejó de funcionar después de la última actualización

Mi foro ya no responde a las respuestas enviadas por correo electrónico.

La función de respuesta por correo electrónico funcionaba correctamente anteriormente, pero parece que dejó de hacerlo alrededor del 29 de septiembre.

No tengo evidencia definitiva de este momento, ya que el foro no es muy activo, pero definitivamente ya no funciona ahora y los registros del foro no muestran mensajes recibidos después del 29 de septiembre.

El registro de correos electrónicos rechazados también tiene su entrada más reciente el 29 de septiembre. Todos los mensajes rechazados tienen direcciones desechables y contenido que parece spam, por lo que esto parece estar funcionando como debería.

El registro de correos electrónicos rebotados está vacío o muestra “no se encontraron registros”.

Los mensajes siguen siendo enviados por el foro generados por la actividad de usuarios registrados (yo al menos los recibo), aunque los niveles de actividad son incluso más bajos de lo normal debido a lo anterior. Casi todos los usuarios activos prefieren el correo electrónico en lugar de la interacción basada en el navegador.

Las respuestas probadas enviadas por correo electrónico a las notificaciones de correos electrónicos de publicaciones del foro, enviadas desde mi propia dirección de correo electrónico alojada en Microsoft o desde mi dirección de Gmail, no reciben advertencias de rebote. Simplemente desaparecen sin dejar rastro. Nada aparece en el registro de correo electrónico del foro.

El registro de errores del foro muestra un par de advertencias (ícono de signo de exclamación amarillo) para el 29 de septiembre: “El correo electrónico no se puede procesar: Email::Receiver::BadDestinationAddress Recibido…”, que parecen inocuas o no diferentes a eventos similares registrados anteriormente. Presumo que son simplemente spam rechazado.

El 1 de octubre se registró un error real como:

Mensaje

ActionDispatch::Http::MimeNegotiation::InvalidType (“%{#context[‘com.opensymphony.xwork2.dispatcher.httpservletresponse’].addheader(‘cbu0psig’” no es un tipo MIME válido)
lib/middleware/omniauth_bypass_middleware.rb:71:in call' lib/content_security_policy/middleware.rb:12:in call’
lib/middleware/anonymous_cache.rb:353:in call' config/initializers/100-quiet_logger.rb:23:in call’
config/initializers/100-silence_logger.rb:31:in call' lib/middleware/enforce_hostname.rb:23:in call’
lib/middleware/request_tracker.rb:187:in `call’

Rastreo

actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:31:in rescue in block in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:24:in block in content_mime_type’
rack (2.2.3) lib/rack/request.rb:69:in fetch' rack (2.2.3) lib/rack/request.rb:69:in fetch_header’
actionpack (6.1.4.1) lib/action_dispatch/http/mime_negotiation.rb:23:in content_mime_type' actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:269:in media_type’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:355:in form_data?' rack (2.2.3) lib/rack/request.rb:445:in POST’
actionpack (6.1.4.1) lib/action_dispatch/http/request.rb:400:in block (2 levels) in POST' actionpack (6.1.4.1) lib/action_dispatch/http/parameters.rb:88:in parse_formatted_parameters’

Entorno

HTTP HOSTS: nzarchitecture.net.nz

No tengo idea de si esto es relevante, y no han aparecido más errores ni errores fatales (denotados con íconos de cruz roja clara u oscura) en el registro desde entonces.

Ninguna de mis direcciones de correo electrónico parece ser spam o estar en listas negras cuando se prueba en www.mail-tester.com, y no se han encontrado problemas al comunicarse con personas desde estas direcciones.

El foro utiliza Mailgun, aunque presumo que esto es solo para enviar correos electrónicos masivos, y que cualquier problema con la cuenta de Mailgun o la clave de API no debería afectar los mensajes entrantes. Por cierto, no hay problemas obvios ni mensajes de error con Mailgun cuando inicio sesión en mi cuenta de Mailgun.

Asumo que la clave de API de Mailgun debe estar bien si el foro sigue enviando correo correctamente.

No se ha cambiado ninguna configuración del foro desde que la respuesta por correo electrónico funcionaba, y veo que la casilla de verificación de la configuración “respuesta por correo electrónico” sigue marcada.

El foro está alojado en Digital Ocean. No se han cambiado las configuraciones DNS para el dominio en la configuración de Digital Ocean, y los registros MX del foro parecen estar bien/inalterados.

El foro se ha actualizado a la versión 2.8.0 beta 7 desde que comenzó el problema (presumiblemente reconstruyendo en el proceso), pero no hay ninguna mejora.

¿Qué me estoy perdiendo aquí?
¿Qué probablemente salió mal?
¿Cómo puedo hacer que la respuesta por correo electrónico vuelva a funcionar?

Ese error parece no estar relacionado.

En general, es más fácil probar “entrada de correo electrónico” que probar “respuesta por correo”. Verifica la configuración de encuestas manuales habilitadas y entrada de correo electrónico, agrega una dirección de correo electrónico a la categoría de personal y comprueba si puedes enviar un correo a esa dirección usando la misma cuenta de correo electrónico que utilizas para tu cuenta de administrador del foro.

Luego, revisa Administración - Correo electrónico - Rebotados / Recibidos / Rechazados para ver qué está sucediendo.

¿Está configurada correctamente tu dirección de respuesta por correo electrónico?

Hola, gracias Richard.

Puedo confirmar que las configuraciones activar sondeo manual y correo entrante siguen activadas.

Agregué mi dirección de Gmail como una dirección personalizada a la categoría de personal, pero no veo ninguna forma de enviar mensajes al personal a través del foro. Todos los enlaces de “contáctenos” están configurados en el texto de la configuración del foro como enlaces mailto: que simplemente van a mi dirección de correo personal de uso diario; al hacer clic en uno de ellos, se abre mi aplicación de correo electrónico, prellenada con mi dirección de correo directa personal, lo que significa que el foro nunca recibiría el mensaje.

No, debes configurar algo como staff@nzarchitecture.net.nz en la configuración de la categoría y luego usar tu Gmail para enviar un mensaje a esa dirección.

Ah, vale.

Lo intenté exactamente así, pero no ha aparecido nada en ningún registro de Rebotados / Recibidos / Rechazados.

tu servidor de correo está configurado en Digital Ocean.

¿Tienes un servidor de correo con ellos?

Esa es la IP del droplet, que está ejecutando el mail-receiver.

nzarchitecture.net.nz. 2727 IN A 159.65.140.176

ha cambiado en los últimos 5 meses

Sé lo que está sucediendo. Es ese maldito asunto de LetsEncrypt que rompió la mitad de internet muchas cosas el 30 de septiembre.

Simplemente reconstruye el contenedor Docker del receptor de correo.

jajajajaja, sí. Lo olvidé. LOL

Debes seguir el tema que publicó @RGJ.

Eso debería solucionar tu problema.

¡Ah, vale! Eso suena prometedor.
¿Cómo puedo reconstruir el ‘receptor de correo Docker’? ¿Es esto diferente a la reconstrucción del ‘gestor Docker’ que ocurre al actualizar el foro mediante el panel de control?

¿Solo sigo esto? ¿Cómo actualizar manualmente Discourse y la imagen Docker a la última versión? - cómo hacer / administradores - Discourse Meta

necesitas iniciar sesión en la interfaz de línea de comandos de tu sitio.

No es a través del panel de administración del foro.

Hola, pude reconstruir el contenedor Docker de recepción de correo siguiendo las instrucciones en ese enlace Entrega directa de correo entrante para sitios autoalojados - cómo hacer / sysadmin - Discourse Meta.

Tuve que actualizar y redimensionar mi droplet de Digital Ocean para hacerlo, ya que incluso después de eliminar todas las copias de seguridad y otros archivos almacenados en el host, no había suficiente espacio en disco para realizar la reconstrucción.

Después de la reconstrucción, pude enviar ese mensaje a staff@nzarchitecture.net.nz y el foro lo reconoció esta vez.
Sin embargo, cuando intento responder por correo electrónico a un tema existente del foro del que he recibido notificaciones, aunque los mensajes entrantes ahora son reconocidos, ninguno aparece en el foro y todos generan advertencias de “Fallo en la entrega de correo” en el registro de correo.

Los mensajes entrantes no aparecen en el registro de correos rebotados, pero sí aparecen todos en el registro de correos rechazados con la advertencia [Email::Receiver::BadDestinationAddress], incluido mi propia cuenta de correo de administrador, la cual espero que no tenga de repente una dirección de destino incorrecta.

¿Ha reconstruido su receptor de correo recientemente?

Sí, hice eso hace media hora aproximadamente, lo que dio como resultado el mensaje anterior.
Acabo de realizar una reconstrucción completa y (toca madera) parece que las cosas vuelven a funcionar.

Podría ser que la opción forzar HTTPS no estaba configurada y la reconstrucción lo solucionó.

De hecho, acababa de ver una advertencia sobre eso exactamente en el panel de control, así que hice clic en el enlace útil proporcionado para la configuración adecuada y marqué la casilla.

No me había dado cuenta de que forzar HTTPS era obligatorio para recibir correos electrónicos entrantes.

Es posible que la falta de HTTPS obligatorio también haya estado causando problemas con el inicio de sesión mediante Facebook: recientemente Facebook me notificó que mi sitio infringía sus términos de servicio y había sido suspendido. No había elementos de acción en el panel de control de desarrollador de mis aplicaciones de Facebook, así que presenté una apelación y la respuesta fue que no podían verificar el sitio debido a un error no especificado generado por la URL de mi foro.

Parece que marcar la casilla ‘forzar https’ no ha ayudado en absoluto con el inicio de sesión de Facebook. El soporte técnico de Facebook sigue indicando que la página de inicio del sitio genera una advertencia de seguridad ‘tu conexión no es privada NET::ERR_CERT_COMMON_NAME_INVALID’ para ellos.

El emisor del certificado, según la página de error, se muestra como ‘R3’, lo que una búsqueda en Google sugiere que está relacionado con Let’s Encrypt, las mismas personas cuyo vencimiento de certificado provocó la necesidad de reconstruir la instalación de Discourse.

¿Es esto una coincidencia? ¿Esto sugiere que la última versión de Discourse (2.8.0 beta 7) todavía tiene un problema con el certificado? ¿O es un problema no relacionado con el alojamiento/Digital Ocean?

Mis propias investigaciones erráticas en Google me llevaron a probar mi URL usando https://www.whynopadlock.com/, cuyos resultados me condujeron a esta publicación de un usuario de Let’s Encrypt.

Let’s Encrypt actualizó recientemente su certificado intermedio de “Let’s Encrypt Authority X3” a “R3”.

Si utilizas un cliente ACME que funcione correctamente, este debería haber comenzado a usar automáticamente el nuevo certificado intermedio en tu última renovación. No deberías haber notado ninguna diferencia.

En tu caso, quizás has estado codificando manualmente el certificado intermedio. Si ese es el caso, necesitarás usar el nuevo certificado intermedio, que puedes encontrar en https://letsencrypt.org/certificates: https://letsencrypt.org/certs/lets-encrypt-r3-cross-signed.pem

¿Es posible que la versión actual de Discourse esté codificando incorrectamente el certificado intermedio?

¿Son los “certificados intermedios” algo que los administradores de Discourse ahora deben gestionar? Y de ser así, ¿cómo?

Por favor, házmelo saber si me he desviado del tema; no estoy seguro de si esto forma parte del mismo problema o no.