Tenemos un flujo de trabajo en el que usamos Discourse como archivo de correo electrónico. Tenemos una dirección de correo electrónico grupal, y nuestros agentes la copian cuando inician un hilo de correo electrónico con un cliente.
Esto funciona muy bien hasta que un cliente responde específicamente al agente, ignorando todas las copias y hasta las cabeceras de Respuesta a. El agente entonces debería reenviar el correo electrónico (reenviar) a la dirección de correo electrónico grupal. Reenviar es el método preferido aquí, para que Discourse archive el correo electrónico original incluyendo todas las cabeceras originales, marcas de tiempo, etc.
Reenviar un correo electrónico se hace copiando el mensaje exacto, y añadiendo las cabeceras Resent-From y Resent-To. Estas son desafortunadamente ignoradas por Email::Receiver. Simplemente debería añadir todos los Resent-* a los campos regulares respectivos.
Empecé a implementar eso, y llegué hasta hacer que create_incoming_email tuviera en cuenta los campos. Pude entonces ver los correos, incluyendo los destinatarios tomados de Resent-To, en la lista de correos entrantes en Discourse.
Sin embargo, lo que no consigo es que get_all_recipients también respete los campos Resent-*. Añadí resent-to resent-cc resent-bb al array %i() de campos de correo, pero todavía no parece devolver los destinatarios de estos campos.
¡Cualquier ayuda es bienvenida, para que pueda hacer un PR para este cambio!
Parece una funcionalidad bastante peligrosa y propensa a la suplantación de identidad. ¿Cómo propone autenticar el reenviador?
Con la cabecera Resent-From. Pero eso en realidad no importa; la parte interesante es si el remitente original puede ser autenticado, no el reenviador.
Además, Discourse ya tiene un procesamiento existente para correos reenviados.
Solo para reenvíos citados. Esto tiene varios problemas:
No archiva el correo original, solo una copia citada de su cuerpo.
No hay soporte para mensajes reenviados como archivo adjunto (con cabeceras completas).
Está incompleto (depende de un prefijo especial en el Asunto para reconocer un correo reenviado).
¿Y cómo sucede eso exactamente? ¿Qué pasa si el reenviador simplemente miente y fabrica completamente un correo electrónico que supuestamente solo le fue enviado a él?
¿Y cómo sucede eso exactamente? ¿Qué pasa si el reenviador simplemente miente y fabrica por completo un correo electrónico que supuestamente se le envió solo a él?
Entonces podrían simplemente omitir todo lo relacionado con Resent- y falsificarlo desde el principio, sin afirmar que se les envió primero.
Creo que tienes una idea equivocada de lo que hacen las cabeceras Resent-, que de hecho no hacen absolutamente nada. Tampoco son tenidas en cuenta cuando los servidores de correo verifican SPF o DKIM, por lo que falsificar un correo reenviado es tan difícil como falsificar el correo original.
En mi caso, un correo reenviado de un extraño sería bloqueado por el filtro de spam por violación de SPF. La razón por la que mi escenario con agentes que reenvían correos a Discourse funciona es que están exentos de esas verificaciones después de autenticarse en nuestro servidor de correo.
Permitir que Discourse utilice la cabecera Resent-To es, por lo tanto, nada más que una característica de conveniencia, porque es la forma en que los clientes de correo habituales crean una copia falsificada de un correo que recibieron anteriormente. No cambia nada sobre la autenticación.