2008-09-23 17 views
13

Tenemos una aplicación web empresarial típica que permite a nuestros usuarios enviar correos electrónicos con ofertas a sus clientes. Configuramos el correo electrónico del usuario en el campo FROM para que el cliente pueda responder directamente al usuario. El problema es que debido al protocolo SMTP, la notificación por correo electrónico no entregada se devuelve a nuestra dirección de correo electrónico (la dirección de la cuenta desde la que enviamos los correos electrónicos).Manejo de correos electrónicos no entregados en la aplicación web

¿Conoces una forma elegante de manejar este correo electrónico no entregado? Me refiero a la forma más fácil de hacerle saber al remitente que su correo no fue entregado.

Respuesta

0

Exactamente qué rutina está utilizando para enviar el correo electrónico? Enviamos correos electrónicos a través de SMTP sin procesar usando put_lines HTTP y las respuestas recuperan la dirección que nominamos en el campo FROM :.

Vea si su envoltorio API SMTP tiene una respuesta a: campo

Algunas API podrían no proporcionar esta funcionalidad, ya que aumenta la posibilidad de envío de correo basura.

3

Hay 3 "Encabezados" que tienen los correos electrónicos.

  1. De.
    • Esto es lo que el usuario ve como el 'iniciador'
  2. Responder-a.
    • Aquí es donde un correo electrónico es enviado si la respuesta se intented
  3. Return-path.
    • Aquí es donde se enruta un correo electrónico en el caso de que el destino no exista.

Es posible que desee estar preparando la tercera :)

(Nota, algunos servidores no responda a estos mensajes perdidos en absoluto, becuase recientemente los spammers han estado poniendo direcciones de ahí que no son su cuenta, haciendo un ataque tercera parte de rebote utilizando el sistema de respuesta automática para activar los servidores de correo electrónico en una retransmisión abierta)

ver sección 4.4 de este documento para más detalles: http://www.faqs.org/rfcs/rfc822.html

17

Primero, es importante entender la diferencia entre el encabezado "De:" (que el destinatario ve en su cliente de correo electrónico) y la dirección del remitente (que también se llama la ruta de devolución del sobre, o el argumento del SMTP "CORREO DE" mando). La dirección del remitente es donde van los mensajes de rebote cuando no se puede entregar el correo electrónico, de ahí la ruta de retorno del otro nombre.

SMTP no restringe la dirección que utiliza como dirección del remitente (excepto que debe ser sintácticamente válida), pero cualquiera que sea la biblioteca de cliente SMTP que utilice, deberá verificarla.

Cambiando la dirección del remitente es donde puede hacer cosas inteligentes para ayudar a detectar los rebotes de correo electrónico y reportarlos a la aplicación web o al remitente. Lo más común que verá es codificar la dirección del destinatario en la dirección del remitente, p. con una dirección de remitente como esta: [email protected] El MTA responsable de senderdomain.com necesita saber para enviar todos los correos electrónicos para [email protected] a [email protected], pero ese es un requisito bastante común. A continuación, toma el correo electrónico que se recibe, y en lugar de tratar de resolver el mensaje de rebote en los contenidos (que podrían estar en cualquier formato) de quién era el destinatario, puede obtenerlo directamente desde la dirección del destinatario.

También puede hacer cosas más complejas, como hash la dirección del destinatario para que no esté visible directamente en la dirección del remitente, p. [email protected] Y podría incluir algún identificador para el correo electrónico que se envió, en caso de que envíe varios correos electrónicos a la misma dirección y desee saber cuál rebotó.

Estos trucos se llaman Variable Envelope Return Path o VERP, y son comúnmente implementados por el software de la lista de correo.

Cuestiones relacionadas