Abriendo una nueva solicitud de características aquí, actualmente Discourse solo permite una única dirección de correo electrónico que se utiliza tanto para envelope-from como para reply-to. Si un sitio desea utilizar su propio dominio SMTP para enviar correos electrónicos pero desea que las respuestas de correo electrónico se envíen a un dominio diferente (por ejemplo, Gmail), los correos electrónicos enviados fallarán DMARC. Al separar estos dos campos de encabezado, se evitará un fallo de DMARC y tampoco se perderá la capacidad de manejar correos electrónicos rebotados.
No veo cómo se manejarán los rebotes en este escenario. Los rebotes van al sobre de origen, no a la dirección en Reply-To. Por lo tanto, si tu sobre de origen no es capaz de manejar correos electrónicos con etiquetas VERP, seguirás en problemas.
En el tema al que haces referencia, no explicas por qué la firma DKIM contra el dominio en la cabecera From: no funciona. Eso debería proporcionar alineación DMARC, incluso si SPF falla. Ese sería el enfoque que tomaría, si estuviera en tu posición (o eso, o ir a los administradores del servidor SMTP entrante de yyy.com con una horca; ¿qué tipo de MTA no admite ningún tipo de direccionamiento detallado?).
Funcionará porque el MTA soporta “catch all”. Aunque no soporta VERP, se puede configurar para reenviar todos los correos no especificados a un correo específico, por lo que las respuestas de rebote no se perderán.
Además, si separamos envelope-from y reply-to, envelope-from no necesita contener una dirección VERP. Puede ser una dirección simple como discourse@yyy.com. Así, cuando rebote, volverá a discourse@yyy.com, lo que no fallará SPF.
El reply-to puede tener un correo diferente que soporte VERP, como discourse-yyy+sdfkj33@gmail.com, de modo que si se entrega correctamente, cuando el usuario responda, llegará al servidor de gmail que soporta VERP y no fallará DMARC ya que el from sigue siendo yyy.com.
Estoy de acuerdo, pero nosotros no los fabricamos. Debido a que tienen direccionamiento “catch-all”, no soportarán VERP. Desafortunadamente, esa es la situación. Espero que con un pequeño ajuste discourse pueda soportar un ecosistema más diverso. Muchos sitios pequeños que usan gmail para gestionar las respuestas estarán en esta situación.
Si tu MTA admite una captura de todos, ¿por qué no puedes reenviar las respuestas con la misma función y eliminar Gmail por completo?
El envelope from es la dirección que debe admitir VERP, porque la única forma de identificar de manera confiable la causa de un rebote es a través de la información en la dirección envelope from del correo electrónico original, como explicó Michael anteriormente (Michael previously explained).
Tengo mis dudas sobre esa afirmación. Usar una dirección de Gmail para las respuestas es cutre, y siempre lo ha sido; el mail-receiver es una forma mucho más sencilla, confiable y menos cutre de manejar las respuestas (y los rebotes).
Incluso para esos sitios pequeños que usan Gmail, los más pequeños probablemente estén ignorando los Términos de Servicio y usando Gmail para el reenvío de salida también, y la gran mayoría del resto probablemente no estén obligados a un MTA que no admita el direccionamiento detallado.
Porque es un “catch all” para el dominio, solo se está utilizando un correo electrónico para Discourse.
No necesariamente, actualmente lo estoy usando sin VERP y está funcionando. Mi problema es que no puedo hacer que el usuario responda directamente a Gmail sin un fallo de SPF/DMARC debido a la forma en que Discourse establece las direcciones envelope-from y reply-to. En cambio, tengo que hacer que el MTA lo reenvíe a Gmail. Si pudiera hacer que respondiera directamente a Gmail (sin un fallo de DMARC/SPF), entonces podría usar VERP para asegurar las respuestas, pero sí, el VERP será ignorado para los correos electrónicos rebotados. Sigue siendo más seguro que la implementación actual.
Esa no es una opción, como expliqué aquí. Solo es práctico usar Gmail para la entrada. Configurar tu propio MX de entrada directo cuando ya tienes un MX de tu proveedor de alojamiento puede ser un desafío para los no iniciados. Las respuestas directas de Gmail son mucho más fáciles y menos propensas a errores.
Quizás me estoy perdiendo algo en tu línea de pensamiento. Solo veo ventajas en separar las direcciones envelope-from y reply-to, ya que soporta ecosistemas más diversos y es más seguro, además de ayudar a evitar fallos de SPF/MARC.
Mi línea de pensamiento es que la respuesta correcta a su problema, tal como se ha expresado hasta ahora, es configurar DKIM. Hacer que la configuración del correo sea aún más complicada y propensa a errores no está justificado por su caso de uso, en mi opinión.
DKIM ya está configurado, el problema es que SPF falla.
Agregar un campo adicional para separar las direcciones envelope-from y reply-to proporcionará mucha flexibilidad y permitirá que SPF también pase (lo cual no pasará si uno tiene un servidor SMTP que reenvía correos electrónicos o no admite VERP). El campo se puede ocultar en la interfaz de usuario o incluso establecer para que coincida con las direcciones envelope-from y reply-to, a menos que los administradores decidan anularlo específicamente. La descripción puede apuntar a esta página. Sin embargo, no veo cómo empeorará las cosas, SÓLO puede mejorar: o son iguales (en cuyo caso SPF fallará en cualquiera de los escenarios descritos aquí) o mejorará la entregabilidad.