ver saber office estado encabezado electronico correo como analizar abrir email header

email - saber - ver encabezado de correo en outlook 2016



Precedencia: encabezado en el correo electrónico (5)

Mi aplicación web envía correos electrónicos con bastante frecuencia y envía 3 tipos de correos electrónicos: iniciados por el usuario, en respuesta a un evento en el sistema y en respuesta automática a un correo electrónico recibido por la aplicación.

Me gustaría asegurarme de que el tercer tipo de correo electrónico no se quede atascado en un ciclo interminable de respuestas automáticas que se comuniquen entre sí. Actualmente, uso el encabezado:

Precedence: junk

pero Yahoo! el correo está tratando estos mensajes como spam. Obviamente, esto no es lo ideal, porque nos gustaría que ALGUIEN lea nuestra respuesta automática y tome una decisión al respecto, pero no una respuesta fuera de la oficina.

¿Cuál es la mejor manera de enviar un correo electrónico sin desencadenar ni filtros basura ni respuestas automáticas?

Precedence: junk? Precedence: bulk? Precedence: list? X-Priority: 2?

¿Qué hay de configurar una lista blanca en su cuenta de correo electrónico?

Asumiría que cualquier palabra clave del correo electrónico podría ser marcada por un filtro basura.

Hay un RFC 3834 dedicado para respuestas automáticas por correo electrónico.

En resumen, recomienda:

  1. Envíe respuestas automáticas solo a la dirección contenida en el encabezado Return-Path de un mensaje entrante, si es una dirección de correo electrónico válida. Particularmente "<>" (dirección nula) en la Return-Path de Return-Path del mensaje significa que no se deben enviar auto-respuestas para este mensaje.

  2. Al enviar la respuesta automática, el comando MAIL FROM smtp debe contener "<>" (dirección nula). Esto llevaría a Return-Path: <> cuando se entregará el mensaje.

  3. Utilice el encabezado Auto-Submitted con un valor que no sea "no" para indicar explícitamente una respuesta automatizada.

Una nota: no vale la pena establecer explícitamente el encabezado Return-Path en el mensaje saliente, ya que este encabezado debe ser reescrito por la dirección envolvente (del comando MAIL FROM smtp) durante la entrega.

La forma tradicional de lidiar con esto es enviar el correo electrónico con un remitente de envolvente nulo (escrito tradicionalmente como <>). Esto evita que el auto respondedor del otro lado responda porque no hay un remitente al que responder.

RFC 2076 desalienta el uso del encabezado de precedencia. como ya habrás notado, muchos clientes simplemente lo filtran (especialmente la prioridad: variedad de basura). puede ser mejor utilizar un camino nulo para evitar guerras de respuesta automática:

Return-Path: <>

En última instancia, podría utilizar la prioridad para tratar de evitar esto, pero esto parece ir en contra del espíritu del encabezado. Sugeriría usar simplemente el encabezado return-path para esto, y evitar la precedencia. en algunos casos, puede que tenga que escribir de alguna manera para soltar respuestas automáticas en su aplicación (para evitar entrar en una guerra de respuesta), pero no recuerdo una situación en la que esto sucedió utilizando una ruta de retorno adecuada. (La mayoría de las guerras de respuesta automática que recuerdo tener que tratar fueron el resultado de correos electrónicos muy mal formados)

Nota: el encabezado Return-Path es, en resumen, el destino de las notificaciones (rebotes, retrasos en la entrega, etc.), y se describe en RFC 2821 , porque SMTP lo requiere. También es un método para eliminar el correo incorrecto (ya que teóricamente todo el correo bueno establecerá un camino de retorno apropiado).