Creo que hacer clic en un campo de “Tipo de correo electrónico”, por ejemplo user_watching_first_post, debería mostrar los detalles del mensaje de rebote recibido del destinatario previsto.
Pero en mi sitio autoalojado obtengo el mensaje de error mencionado anteriormente. ¿Hay algo que pueda hacer para solucionarlo?
Gracias.
Eso es correcto. Acabo de verificarlo en mi sitio de Discourse alojado y funciona sin problemas. Si tu sitio está en la última versión de Discourse, me pregunto si el problema está relacionado con la forma en que tu servidor de correo maneja el reenvío del mensaje de rebote.
Gracias. Para el correo saliente estoy usando Mailgun. Creo que usé la configuración recomendada por Discourse.
Para el correo entrante estoy usando esto: Configure direct-delivery incoming email for self-hosted sites with Mail-Receiver, pero nunca lo he actualizado desde la instalación. ¿Podría ser ese el problema? Dado que para Discourse se usa ./launcher rebuild app, ¿es ./launcher rebuild mail-receiver?
Sí, así es como se actualiza. Ha pasado un tiempo desde la última actualización, creo, pero un buen primer paso sería actualizarlo y a Discourse.
He actualizado ambos y sigo obteniendo el mismo error, incluyendo (creo) los correos electrónicos recibidos desde la actualización. ¿Tienes alguna otra idea?
El mismo problema aquí. Auto-alojado, actualizado. Los rebotes se están manejando de la manera recomendada. Los enlaces anteriores al cambio a un manejo adecuado de rebotes funcionan bien.
Sí, es probable que Discourse no lo esté recibiendo desde Mailgun. No sé cómo funcionan los webhooks, pero sospecho que simplemente le indican a Discourse que ha ocurrido un fallo temporal o permanente sin enviar el mensaje de rebote.
¿Existe alguna forma de que esta función de Discourse funcione con Mailgun?
Debería ser posible mostrar al menos el código de error y el mensaje:
Tanto el código de error SMTP como el mensaje de error SMTP se conservan
“code”: 550,
“address”: “'baz@example.com”,
“error”: “Message was not accepted – invalid mailbox. Local mailbox 'baz@example.com is unavailable: user not found”
https://documentation.mailgun.com/en/latest/api-bounces.html#examples
Si no es así, al menos necesitamos un mensaje de error lógico que explique por qué el enlace no funciona 
¿Se ha hecho algo al respecto? Estaría muy agradecido si así fuera
Uso Digital Ocean y Mailgun (es decir, las principales recomendaciones), así que imagino que no soy el único con el problema.
Después de mis propias pruebas, parece que en muchos casos, los rebotes no son recibidos en absoluto por el receptor del correo. (Solo encontré un intento de conexión para uno, que se perdió de inmediato). No veo que la cabecera Return-Path se establezca en absoluto (¿se supone que debe hacerlo?), lo que me hace pensar que la mayoría de las veces ni siquiera se envían de vuelta.
Sigue siendo un problema aquí también. A pesar de mi declaración anterior, ahora parece que ninguno de estos enlaces funciona, volviendo al inicio del sitio. Inicialmente, solo parecía afectar a los rebotes de antes de que empezáramos a gestionar los rebotes correctamente (Configure VERP to handle bouncing e-mails).
Acabo de notar un montón de advertencias en el registro de errores parecidas a estas:
No se puede procesar el correo electrónico: Email::Receiver::AutoGeneratedEmailError
Recibido: de ...
para <bounce+f7e463.5f70e9-...@forum.example.com>; ...
Asunto: No se pudo entregar su mensaje
Quizás esta sea la razón por la que Discourse no tiene detalles sobre los correos electrónicos rebotados.
No veo esos errores en los registros, pero el problema persiste. Cuando hago clic en el valor del tipo de correo electrónico en una entrada de la lista de correos rebotados, obtengo “Ocurrió un error: Discourse::NotFound”.
Ya estaba seleccionado. Retrocedí un poco más en el registro y, aunque veo mensajes ocasionales relacionados con el correo electrónico, no veo los que mencionaste.
Tengo el mismo problema con Mailgun. Es un host diferente, ¡así que no es eso!
Me pregunto si hay un problema con las instrucciones de configuración de Mailgun para la configuración de VERP:
Esto ha estado ahí por un tiempo, pero recién ahora está empezando a causar problemas mientras intento investigar por qué estoy recibiendo tantos rebotes en este momento.
El problema parece ser que no hay enlace en la columna Email Type y nada detrás del ícono 
(flechas rojas):
Cuando hago clic en estos, obtengo esto:
Investigando el código de la página, las etiquetas anchor en el HTML parecen carecer por completo del href:
Tengo VERP configurado para Mailgun, y parece estar funcionando bien en otros aspectos.
Ese es el comportamiento esperado cuando la respuesta rebotada no fue procesada por Discourse. La función funciona bien si Discourse recibe los rebotes, de lo contrario, mostrará esa respuesta para todos los rebotes.
¿Puede verificar y ejecutar la prueba de acuerdo con Configure VERP to handle bouncing e-mails?
Un mejor mensaje sería bueno en ese caso.
Creo que quieres decir que si Discourse solo se entera del rebote a través de un webhook de Mailgun, los detalles del rebote nunca se envían a Discourse. ¿Es correcto?
Si es correcto, ¿habría alguna forma de que esos detalles se envíen a Discourse y se registren y muestren en el mismo lugar que los rebotes recibidos por Discourse? Creo que la API de Mailgun lo permitiría ("Discourse::NotFound" error when click "Email Type" field on admin/email/bounced - #8 by Jonathan5).
¿En qué circunstancias manejaría Discourse los rebotes en lugar del servicio de correo electrónico externo? (Sé que Discourse puede rebotar/rechazar correos electrónicos, pero me refiero a manejar los mensajes de rebote recibidos de los destinatarios de correo electrónico previstos).
De acuerdo. Si algo no está realmente roto, no debería parecer que lo está. Discourse seguramente puede proporcionar un mensaje más tranquilizador.
