verificar txt remitentes registro google con check autorizar all email spf

email - txt - Posibles problemas al usar la dirección "de" del miembro y el encabezado "remitente"



txt spf (1)

Así que decidí responder mi propia pregunta ya que nadie más respondió. Quizás otros encuentren esta entrada cuando busquen.

Lo que finalmente estamos haciendo es esto:

Establezca el encabezado From en la dirección de correo electrónico real del usuario.

From: "Mary Smith" <[email protected]>

Use un encabezado de remitente con la dirección de correo electrónico amplia del sistema.

Sender: <[email protected]>

Finalmente, el remitente real que aparece en el encabezado MAIL FROM / Return Path del servidor se establece con un identificador único, es decir,

Return Path: "Mary Smith" <[email protected]>

Eso permite que un programa que se ejecute en [email protected] intercepte esas respuestas automáticas y las envíe a la persona a la que originalmente intentaron llegar. La mayoría de los clientes de correo electrónico reales responderán al encabezado De :. No he visto problemas de los usuarios de blackberry ni de otros que responden a la cuenta del sistema.

Después de un mes más o menos en producción, hemos tenido menos problemas con esto que con el método anterior que estábamos usando.

El encabezado del remitente agrega una pequeña nota en los clientes de Microsoft Outlook sobre "On Behalf Of", pero eso es apropiado para nuestro uso. No ha habido ningún problema con SPF en clientes comunes / mta con esta configuración (Gmail, Yahoo, SpamAssassin, etc.)

Actualización: en abril de 2014, Yahoo y AOL cambiaron sus configuraciones de DMARC para dejar caer este tipo de mensajes sin previo aviso. (Cambiaron a p = rechazar, consulte https://wordtothewise.com/2014/04/brief-dmarc-primer/ para obtener más información.) Nuestra solución fue en casos especiales esos dominios, ya que la funcionalidad necesaria aún funciona con la gran mayoría de dominios

IF ISP MATCHES YAHOO OR AOL From: "Mary Smith" <[email protected]> Reply-To: "Mary Smith" <[email protected]> Return Path: "Mary Smith" <[email protected]> ELSE From: "Mary Smith" <[email protected]> Sender: <[email protected]> Return Path: "Mary Smith" <[email protected]> END

Un componente principal de nuestra aplicación envía correos electrónicos a los miembros en nombre de otros miembros. Actualmente configuramos la dirección "De" a nuestra dirección del sistema y usamos un encabezado "Responder a" con la dirección del miembro. El problema es que las respuestas de algunos clientes de correo electrónico (y respuestas automáticas / rebotes) no respetan el encabezado "Responder a", por lo que se envían a la dirección de nuestro sistema, enviándolas efectivamente a un agujero negro. Estamos considerando establecer la dirección "De" en la dirección de nuestro miembro y la dirección "Remitente" en la dirección de nuestro sistema. Parece que de esta manera pasaría las comprobaciones de SPF y ID de remitente.

¿Hay alguna razón para no cambiar a este método? ¿Hay algún otro problema potencial?

Aquí hay muchos más detalles de los que probablemente necesite:

Cuando la aplicación se desarrolló por primera vez, simplemente cambiamos la dirección "de" para que fuera la del miembro remitente, ya que esa era la práctica común en ese momento (esto fue hace muchos años). Más tarde cambiamos eso para que la dirección "de" fuera el nombre del miembro y nuestra dirección, es decir,

De: "Mary Smith" <[email protected]>

Con un encabezado de "respuesta a" establecido en la dirección del miembro:

Responder a: "Mary Smith" <[email protected]>

Esto ayudó a que los mensajes se clasificaran erróneamente como correo no deseado. A medida que SPF se hizo más popular, agregamos un encabezado adicional que funcionaría junto con nuestros registros SPF:

Remitente: <[email protected]>

Las cosas funcionan bien, pero resulta que, en la práctica, algunos clientes de correo electrónico y la mayoría de los MTA no respetan el encabezado "Responder a". Debido a esto, muchos miembros envían mensajes a [email protected] en lugar del miembro deseado.

Entonces, comencé a imaginar varios esquemas para agregar datos sobre el remitente a los encabezados del correo electrónico o codificarlo en la dirección de correo electrónico "desde" para que pudiéramos procesar la respuesta y redirigir de manera apropiada. Por ejemplo,

De: "Mary Smith" <[email protected]>

donde la cadena después de "mensajes" es un hash que representa el miembro de Mary Smith en nuestro sistema. Por supuesto, ese camino podría causar mucho dolor ya que necesitamos desarrollar la funcionalidad de MTA para nuestra dirección del sistema. Estuve mirando nuevamente la documentación de SPF y encontré esta página interesante:

http://www.openspf.org/Best_Practices/Webgenerated

Muestran dos ejemplos, el de evite.com y el de egreetings.com. Básicamente, evite.com lo está haciendo de la manera que lo estamos haciendo. El ejemplo de egreetings.com utiliza la dirección del miembro desde un encabezado "Remitente" agregado.

Entonces, la pregunta es, ¿hay algún problema potencial con el uso del método de saludos de la dirección del miembro desde un encabezado de remitente? Eso eliminaría las respuestas que los clientes malos envían a la dirección del sistema. No creo que resuelva el problema del rebote / vacaciones / lista blanca, ya que a menudo se envía al CORREO desde incluso si se especifica la Ruta de retorno.