2008-09-30 19 views
35

Mi aplicación web envía correos electrónicos bastante a menudo, 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.Precedencia: cabecera en el correo electrónico

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 disparar ni filtros basura ni autoresponders?

Precedence: junk? 

Precedence: bulk? 

Precedence: list? 

X-Priority: 2? 

Respuesta

16

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 una ruta nula para evitar guerras de respuesta automática:

Return-Path: <> 

En última instancia se podría utilizar prioridad para tratar de evitar esto, pero esto parece que va en contra del espíritu de la cabecera. 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 respondedores automáticos 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 es requerido por SMTP. 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).

+0

¿Puede explicar para qué se usa Return-Path? (Supongo que es muy diferente al encabezado Reply-To) –

+0

en resumen, es el destino de las notificaciones (rebotes, retrasos en la entrega, etc.), y se describe en RFC 2821. porque SMTP lo requiere, también un método para eliminar el correo malo (como teóricamente todo el correo bueno establecerá una ruta de retorno adecuada) – Owen

-3

¿Qué le parece si configura una lista blanca en su cuenta de correo electrónico?

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

+1

no puedo ir a Yahoo! y diles que coloquen mi aplicación en una lista blanca, si eso es lo que querías decir. –

0

La forma tradicional de manejar 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.

25

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

En resumen, se recomienda:

  1. Enviar respuestas automáticas sólo a la dirección contenida en la cabecera Return-Path de un mensaje entrante, si se trata de dirección de correo electrónico válida. Particularmente "<>" (dirección nula) en el 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 la respuesta automática.

Una nota: no vale la pena establecer explícitamente cabecera Return-Path en el mensaje de salida, ya que esta cabecera debe ser reescrita por dirección envoltura (de comando MAIL FROM SMTP) durante el parto.

+1

Creo que el # 3 anterior debe ser "Enviado automáticamente", y puede ser "no" (correo humano), "respuesta automática" "(rebotes, avisos de vacaciones) o" generado automáticamente "(trabajos cron de estado diario, etc.) –

+0

Al marcar los encabezados, ¿aún necesito verificar el sujeto para detectar auto respondedores? – user4271704

+0

¿podemos confiar en AutoEnviado = respuesta automática para filtrar los mensajes devueltos de los normales? ¿Todos los servidores de correo/clientes respetan RFC 3834? al menos los más importantes? –

Cuestiones relacionadas