Estoy tratando de averiguar cómo hacer que Discourse limpie las listas de correo electrónico, específicamente los correos electrónicos rebotados. El sitio está utilizando un servidor SMTP privado para enviar correos electrónicos, pero la respuesta se configura para que regrese a una dirección de Gmail para el acceso POP por parte de Discourse.
Así que veo correos electrónicos rebotados en el panel de Correos electrónicos recibidos.
Discourse usa la reply_key para asociar los rebotes con los correos electrónicos enviados. Cuando Discourse envía correos, usa el valor de reply_by_email_address como remitente del sobre SMTP.
Necesitas asegurarte de que tu reply_by_email_address incluya una {reply_key} para que tu instancia pueda asociar los rebotes con el correo electrónico correcto enviado.
Por ejemplo, aquí en meta está configurado a incoming+%{reply_key}@meta.discoursemail.com y cualquier cosa enviada a esa dirección se entrega a esta instancia.
Gracias por la respuesta. Desafortunadamente, he tenido que desactivar la reply_key de la respuesta al correo electrónico porque nuestro servidor de retransmisión de correo electrónico no reconoce la dirección +. ¿Hay alguna otra opción?
Tu servidor de retransmisión de correo electrónico no debería importar, solo el servidor final donde reside el buzón. Las partes locales del correo electrónico son opacas para cualquier servidor intermedio.
¿No es Gmail según:
No estoy seguro de si tenemos otro mecanismo para detectar rebotes de manera confiable.
Para aclarar, el servidor de dominio SMTP de destino que recibe el correo electrónico devuelto no reconoce la dirección +, por lo que solo reenvía correos electrónicos basándose en el campo To a la dirección de Gmail que es recogida por Discourse a través de POP. Eso significa que si el campo To incluye la reply_key, no reenviará ese correo electrónico a la cuenta de Gmail utilizada por Discourse.
Entonces, no puedo poner la reply_key en la dirección de correo electrónico, ¿se puede poner en otro lugar? ¿En el campo del asunto o en el cuerpo o en algún lugar donde Discourse pueda analizarla?
El correo electrónico enviado por Discourse proviene de discourse@xxx.com a través de un servidor SMTP de dominio dedicado configurado para Discourse (usando la dirección de dominio de Discourse).
Cualquier respuesta o cuando un correo electrónico rebota, el servidor SMTP del dominio reenvía el correo electrónico a discourse.xxxx@gmail.com. Este servidor SMTP de dominio no puede reconocer la dirección +, por lo que si incluyo la reply_key en la dirección de correo electrónico de respuesta, el servidor SMTP del dominio la descartará. Solo puedo establecer reglas para reenviar direcciones de correo electrónico entrantes discretas/únicas.
El foro de Discourse luego usa POP a través de GMail para acceder a esas respuestas/correos electrónicos rebotados reenviados y los analiza.
Entiendo lo que dices. Desafortunadamente, debido a una limitación de las reglas del servidor SMTP, no puedo configurar el reenvío para subdominios, solo puedo configurarlo para reenviar identificadores de correo electrónico To únicos.
Sin embargo, tengo una aclaración aquí, más bien una discrepancia en cómo parece estar funcionando Discourse:
Cuando un usuario responde a una publicación por correo electrónico, llega correctamente; las respuestas parecen funcionar perfectamente incluso sin que se configure explícitamente ninguna {reply_key} en ningún lugar (ver las capturas de pantalla anteriores).
Sin embargo, cuando un correo electrónico es rebotado, Discourse lo clasifica como Recibido en lugar de Rebotado.
Los registros de errores muestran que algo en Discourse reconoce que es un correo electrónico rebotado (ver el registro de errores de mi primera publicación). Entonces, si algo en Discourse reconoce que es un correo electrónico rebotado, ¿por qué no aparece como Rebotado en lugar de Recibido?
Entonces, ¿por qué, cuando un usuario responde a una publicación, es procesado correctamente por Discourse, pero no un correo electrónico rebotado (y también parece haber una desconexión entre los registros de errores y el panel para correos electrónicos rebotados)? ¿Me estoy perdiendo algo en la configuración?
También he intentado configurar los ajustes de dirección de respuesta por correo electrónico en Discourse a discourse.xxx+%{reply_to}@gmail.com, pero cuando se entrega el correo electrónico, Gmail parece pensar que el dominio yyy.com (dominio SMTP de Discourse) está intentando suplantar el dominio de Gmail y termina marcándolo como spam. Parece que establecer un dominio de respuesta diferente al dominio de los remitentes está activando un fallo de DMARC y SPF.
ARC-Authentication-Results: i=1; mx.google.com;
spf=softfail (google.com: domain of transitioning discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com does not designate y.y.y.y as permitted sender) smtp.mailfrom=discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com;
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=yyy.com
Return-Path: <discussion.xxx+verp-b9c40db917ca04993dd3433cc9748518@gmail.com>
Has desactivado find related posts with key (espero que hayas leído la advertencia), por lo que Discourse utiliza la cabecera de correo in-reply-to para determinar a qué tema/publicación debe hacer referencia la respuesta.
No puede hacer eso para los rebotes: Discourse necesita saber el mensaje específico que rebotó y esa información solo se garantiza que esté en un lugar: la dirección To: (que proviene de la dirección envelope-from del mensaje original).
Para que esto funcione, cuando Discourse envía un mensaje, necesita recibir la respuesta desde la dirección desde la que provino. Discourse busca esto en la cabecera To: (no en la envelope-to).
está falsificando el dominio de gmail
Si quieres enviar correos electrónicos desde una dirección de gmail, necesitas enviarlos a través de sus servidores. Pero no les gusta eso.
No parece que hayas configurado DKIM para yyy.com; deberías hacerlo. Si lo haces bien, DMARC debería pasar.
Sí, está configurado y el correo electrónico “enviado” por Discourse a través del servidor SMTP de yyy.com pasa SPF, DKIM y DMARC sin problemas (al menos desde la página “Enviar correo electrónico de prueba” en la consola de administración).
Este problema ocurre si configuro una dirección de Gmail como reply_by_email_address a una dirección de gmail.com en lugar de la dirección de yyy.com. ¿Hay algo que pueda hacer para esta configuración para que DMARC no falle cuando se establece como reply_by_email_address a una dirección de Gmail mientras se mantiene el servidor de salida como yyy.com?
¿No puede analizar el resto del contenido/archivos adjuntos en el correo electrónico devuelto para extraer esa información si no puede encontrar lo que necesita en el lugar “obvio” (o al menos proporcionar una opción en la configuración para hacerlo con las advertencias necesarias sobre la suplantación de identidad)?
La alineación DMARC falla ya que la reply_by_email_address se utiliza como la dirección del remitente del sobre en esta situación.
Prácticamente lo único que se garantiza que está intacto en un rebote es la dirección.
Quizás el asunto, pero no sería práctico poner esta información allí.
Veo que algunos sistemas incluyen el mensaje original como un archivo adjunto… teóricamente es posible que podamos verificar los rebotes en busca de un archivo adjunto para obtener más información si existen.
Si entiendo esto correctamente, la reply_by_email_address debería establecerse en el campo reply-to del sobre enviado por Discourse (desde yyy.com). Entonces, cuando el usuario responde, responde al correo electrónico reply-to (gmail.com) en lugar de a la dirección original (yyy.com). Por lo tanto, en el sobre de respuesta del correo electrónico, la dirección from debería ser la dirección de correo electrónico del usuario y el to la dirección gmail.com.
¿Por qué se utilizaría la reply_by_email_address como la dirección from?
la reply_by_email_address no se usa como la dirección de remitente, sino como el envelope-from, específicamente para que funcionen los rebotes.
Aquí tienes una imagen que demuestra cómo se utiliza cada dirección. Las direcciones en sí son específicas de nuestro hosting, pero deberían ser suficientes como ejemplo.
Entonces, básicamente, reply_by_email_address se usa en la cabecera from para que regrese a esa dirección de correo electrónico si rebota. Y la misma dirección de correo electrónico también se establece en la cabecera reply-to si las respuestas por correo electrónico están habilitadas.
Por lo tanto, si mi comprensión anterior es correcta, entonces si Discourse puede tener una configuración separada (reply_to_email) para la cabecera reply-to, eso resolvería el problema del fallo de DMARC. Al usar el dominio yyy.com (tomado de reply_by_email_address) para from al enviar y gmail.com para reply-to (tomado de una nueva configuración reply_to_email). Si el correo electrónico rebota, aún se devolverá a reply_by_email_address, pero si el usuario responde, irá a reply_to_email.
Para pasar DMARC, SPF (que valida el envelope-from en combinación con la IP de envío) o DKIM (que valida el From y los campos de suma de verificación del mensaje) tienen que alinearse.
Parece que el propósito de todo este ejercicio es tener una dirección de respuesta “bonita” a la que los usuarios respondan.
¿Quieres algo como esto?
envelope-from: outgoing+12309847801923840923502389423@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
Debes tener ese envelope-from así, o los rebotes no funcionarán.
Sí, eso es correcto. La idea es tener el envelope-from diferente del reply-to.
Dado que el dominio envelope-from y la IP de envío coinciden, el SPF debería pasar, pero al mismo tiempo la respuesta puede ir a GMail para procesar las respuestas y si el correo debería rebotar, volverá al servidor de dominio original, que luego puede reenviar el rebote a la bandeja de entrada de GMail también.
En realidad, se vería así:
envelope-from: outgoing@yyy.com
…
From: notifications@yyy.com
To: user@contoso.com
Reply-to: my_sweet_forum+12309847801923840923502389423@gmail.com
En mi configuración, el saliente no tendrá un VERP porque mi SMTP entrante no admite VERP (es decir, el rebote no tendrá una dirección VERP), es por eso que el reply-to se envía a GMail porque admite VERP. Esto no debería causar un fallo de DMARC, como ocurre ahora.
