que email smtp rfc email-client bounce

que - return-path email



¿Cuál es la diferencia de comportamiento entre return-path, reply-to y from? (4)

Comencemos con un ejemplo simple. Supongamos que tiene una lista de correo electrónico que enviará el siguiente contenido de RFC2822.

From: <[email protected]> To: <[email protected]> Subject: Super simple email Reply-To: <[email protected]> This is a very simple body.

Ahora, digamos que lo va a enviar desde una lista de correo, que implementa VERP (u otro mecanismo de seguimiento de rebote que usa una ruta de retorno diferente). Digamos que tendrá un camino de retorno de [email protected]. La sesión SMTP podría verse así:

{S}220 workstation1 Microsoft ESMTP MAIL Service {C}HELO workstation1 {S}250 workstation1 Hello [127.0.0.1] {C}MAIL FROM:<[email protected]> {S}250 2.1.0 [email protected] OK {C}RCPT TO:<[email protected]> {S}250 2.1.5 [email protected] {C}DATA {S}354 Start mail input; end with <CRLF>.<CRLF> {C}From: <[email protected]> To: <[email protected]> Subject: Super simple email Reply-To: <[email protected]> This is a very simple body. . {S}250 Queued mail for delivery {C}QUIT {S}221 Service closing transmission channel

Donde {C} y {S} representan los comandos de Cliente y Servidor, respectivamente.

El correo del destinatario se vería así:

Return-Path: [email protected] From: <[email protected]> To: <[email protected]> Subject: Super simple email Reply-To: <[email protected]> This is a very simple body.

Ahora, describamos los diferentes "DESDE" s.

  1. La ruta de retorno (a veces llamada ruta inversa o envolvente-DESDE: todos estos términos se pueden usar indistintamente) es el valor utilizado durante la sesión SMTP. Como puede ver, no es necesario que tenga el mismo valor que se encuentra realmente en los encabezados de correo. Solo se supone que el servidor de correo del destinatario debe agregar un encabezado Return-Path al principio del correo electrónico. Esto registra el remitente de ruta de retorno real durante la sesión SMTP. Si ya existe un encabezado de Retorno de ruta en el correo electrónico, ese encabezado debe ser eliminado y reemplazado por el servidor de correo del destinatario.

    Todos los rebotes que se producen durante la sesión SMTP deben volver al valor Return-Path. Algunos servidores pueden aceptar todo el correo electrónico y luego ponerlo en cola localmente, hasta que tenga un hilo libre para entregarlo al buzón del destinatario. Si el destinatario no existe, debe volver al valor registrado Return Path.

    Tenga en cuenta que no todos los servidores de correo obedecen esta regla. Algunos servidores de correo lo devolverán a la dirección FROM.

  2. La dirección FROM es el valor que realmente se encuentra en el encabezado FROM. Se supone que esto es de quien es el mensaje. Esto es lo que ve como el "DESDE" en la mayoría de los clientes de correo. Si un correo electrónico no tiene un encabezado Responder-A, entonces todas las respuestas humanas (cliente de correo) deben volver a la dirección DESDE.

  3. El remitente (o el software del remitente) agrega el encabezado Responder a. Es donde todas las respuestas humanas deberían abordarse también. Básicamente, cuando el usuario hace clic en "responder", el valor de respuesta debe ser el valor utilizado como el destinatario del correo electrónico recién creado. El valor de Responder no debe ser utilizado por ningún servidor. Está destinado para el uso del lado del cliente.

    Sin embargo, como puede ver, no todos los servidores de correo obedecen los estándares o recomendaciones de RFC.

Espero que esto ayude a aclarar las cosas. Sin embargo, si me perdí algo, házmelo saber e intentaré responder.

En nuestra aplicación de correo estamos enviando correos electrónicos con el siguiente encabezado:

FROM: [email protected] TO: [email protected] Return-PATH: [email protected]

El problema al que nos enfrentamos es que algunos servidores de correo electrónico rebotan un mensaje de inmediato y utilizan la ruta de origen o inversa ([email protected]) en lugar de nuestro servidor bounce mgmt. Queremos saber si modificamos en el encabezado el reply-to para que sea el mismo que el return-path si podremos capturar todos los rebotes.

¿Otras ideas son bienvenidas?

Estamos utilizando los siguientes documentos como referencias: VERP RFC Bounce Messages

SMTP Log Parsing para obtener rebotes

EDIT 1: Unos pocos bits más de información para ver si podemos obtener esta resolución.

Queremos saber en qué punto el servidor de correo electrónico que transmite el mensaje elegirá usar la respuesta frente a la ruta de retorno. Hemos notado que cuando el primer servidor smtp retransmite el mensaje se rechaza lo envía a la respuesta, pero cuando ocurre después de un salto lo envía a la ruta de retorno.


Otra forma de pensar en Return-Path vs Reply-To es compararlo con el correo postal.

Cuando envía un sobre por correo, especifica una dirección de devolución . Si el destinatario no existe o rechaza su correo, el administrador del correo devuelve el sobre a la dirección de devolución. Para el correo electrónico, la dirección de retorno es la Return-Path .

Dentro del sobre puede haber una letra y dentro de la carta puede indicar al destinatario "Enviar correspondencia a una dirección de ejemplo ". Para correo electrónico, la dirección de ejemplo es la Reply-To .

Básicamente, una Dirección de devolución de franqueo es comparable al encabezado de Return-Path SMTP y el encabezado Reply-To de SMTP es similar a las instrucciones de respuesta contenidas en una carta.


Tuve que agregar un encabezado Return-Path en correos electrónicos enviados por una instancia de Redmine. Estoy de acuerdo con greatwolf solo el remitente puede determinar un Return-Path correcto (no predeterminado). El caso es el siguiente: los correos electrónicos se envían con la dirección de correo electrónico predeterminada: [email protected]. Pero queremos que el usuario real que inicia la acción reciba los correos electrónicos de rebote, porque él será quien sepa cómo arreglar los correos electrónicos equivocados de los destinatarios. (y no los administradores de la aplicación que tienen otros gatos para azotar :-)). Usamos esto y funciona perfectamente con exim en el servidor de aplicaciones y zimbra como el servidor de correo final de la compañía.


para los que llegaron aquí porque el título de la pregunta:

Uso Reply-To: dirección con formularios web. cuando alguien llena el formulario, la página web envía un correo electrónico automático al propietario de la página. From: es la dirección del remitente de correo automático, por lo que el propietario sabe que es del formulario web. pero la dirección Reply-To: es la que el usuario rellena en el formulario, por lo que el propietario puede presionar responder para contactarlos.