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 devolverán un mensaje de inmediato y utilizarán la ruta desde o hacia atrás ([email protected]) en nuestro servidor de administración de devolución. Queremos saber si modificamos en el encabezado que la respuesta sea la misma que la ruta de retorno si podremos capturar todos los rebotes.
¿Otras ideas son bienvenidas?
Estamos utilizando los siguientes documentos como referencias: VERP RFC Bounce Messages
Análisis de registros SMTP para obtener rebotes
EDITAR 1: Un poco más de información para ver si podemos obtener esta resolución.
Queremos saber en qué momento el servidor de correo electrónico que retransmite el mensaje elegirá usar la respuesta a la ruta de retorno. Hemos notado que cuando el primer servidor smtp que retransmite el mensaje es rechazado, lo envía a la respuesta, pero cuando ocurre después de un salto, lo envía a la ruta de retorno.
Respuestas:
Comencemos con un ejemplo simple. Supongamos que tiene una lista de correo electrónico, que enviará el siguiente contenido RFC2822 .
Ahora, supongamos que lo va a enviar desde una lista de correo, que implementa VERP (o algún otro mecanismo de seguimiento de rebote que utiliza una ruta de retorno diferente). Digamos que tendrá un camino de retorno de
[email protected]
. La sesión SMTP podría verse así:Donde {C} y {S} representan los comandos Cliente y Servidor, respectivamente.
El correo del destinatario se vería así:
Ahora, describamos los diferentes "DE".
MAIL FROM
comando. Como puede ver, no es necesario que sea el mismo valor que se encuentra en los encabezados de los mensajes. Se supone que solo el servidor de correo del destinatario agrega un encabezado de ruta de retorno a la parte superior del correo electrónico. Esto registra el remitente de la ruta de retorno real durante la sesión SMTP. Si ya existe un encabezado de ruta de retorno en el mensaje, ese encabezado se elimina y se reemplaza por el servidor de correo del destinatario.Todos los rebotes que ocurren durante la sesión SMTP deben volver a la dirección de la ruta de retorno. 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 devolverlo al valor de Ruta de retorno registrado.
Tenga en cuenta que no todos los servidores de correo obedecen esta regla; Algunos servidores de correo lo devolverán a la dirección DE.
La dirección FROM es el valor que se encuentra en el encabezado FROM. Se supone que es de quién es el mensaje. Esto es lo que ve como "DE" en la mayoría de los clientes de correo. Si un correo electrónico no tiene un encabezado de respuesta, todas las respuestas humanas (cliente de correo) deben volver a la dirección DE.
El remitente (o el software del remitente) agrega el encabezado Responder a. Es donde también deben abordarse todas las respuestas humanas. Básicamente, cuando el usuario hace clic en "responder", el valor de Responder a debe ser el valor utilizado como destinatario del correo electrónico recién redactado. El valor de Responder a no debe ser utilizado por ningún servidor. Está destinado solo para uso del lado del cliente (MUA).
Sin embargo, como puede ver, no todos los servidores de correo obedecen los estándares o recomendaciones de RFC.
Esperemos que esto ayude a aclarar las cosas. Sin embargo, si me perdí algo, avíseme y trataré de responder.
fuente
return-path
se usa. Sireturn-path
está destinado a ser una dirección de devolución, ¿por qué el servidor de correo del destinatario completará este campo en lugar del remitente? ¿Cómo sabría el servidor del recetante qué poner allí? ¿No parece esto al revés?Sender:
encabezado en todo esto?Otra forma de pensar en
Return-Path
vsReply-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 de correo devuelve el sobre a la dirección de devolución. Para el correo electrónico, la dirección de devolución es el
Return-Path
.Dentro del sobre puede haber una carta y dentro de la carta puede dirigir al destinatario a "Enviar correspondencia a la dirección de ejemplo ". Para el correo electrónico, la dirección de ejemplo es
Reply-To
.En esencia, una dirección de devolución de franqueo es comparable al
Return-Path
encabezado de SMTP y elReply-To
encabezado de SMTP es similar a las instrucciones de respuesta contenidas en una carta.fuente
Return-Path
encabezado lo agrega el servidor de correo receptor y no el remitente . Por lo que es de la misma familia: usted puede escribir lo que la dirección que desee en el interior del sobre, pero para entregar a ella hay que llevarlo a la oficina de correos y mostrarles su licencia de conducir (u otra identificación) y que poner esa dirección en el sobre antes de enviarlo. En otras palabras, elReturn-Path
encabezado es tan confiable como las comprobaciones realizadas por el servidor SMTP receptor, donde los demás se pueden suplantar fácilmente.para aquellos que llegaron aquí porque el título de la pregunta:
Yo uso la
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. elFrom:
es la dirección del remitente de correo automático, por lo que el propietario sabe que es desde el formulario web. pero laReply-To:
dirección es la completada en el formulario por el usuario, por lo que el propietario puede presionar responder para contactarlos.fuente
Tuve que agregar un encabezado Return-Path en los correos electrónicos enviados por una instancia de Redmine. Estoy de acuerdo con greatwolf, solo el remitente puede determinar una ruta de retorno correcta (no predeterminada). 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 devolución, porque él será quien sepa cómo corregir los correos electrónicos de los destinatarios incorrectos (y no los administradores de aplicaciones que tienen otros gatos para azotar :-)). Utilizamos esto y funciona perfectamente bien con exim en el servidor de aplicaciones y zimbra como el servidor de correo final de la compañía.
fuente