¿Cuál es la diferencia entre Sender, From y Return-Path?

138

¿Cuál es la diferencia entre el remitente de un correo electrónico, el valor From y la ruta de retorno?

Ejemplo : Tengo un formulario de contacto donde el usuario puede ingresar su correo electrónico, ¿se le asignaría al remitente, desde o ruta de retorno?

Tuve una búsqueda rápida en el StackOverflow y no pude encontrar nada útil.

email smtp

— The Pixel Developer
fuente

Respuestas:

172

Entonces, a través de SMTP cuando se envía un mensaje, el sobre SMTP (remitente, destinatarios, etc.) es diferente de los datos reales del mensaje.

El Senderencabezado se utiliza para identificar en el mensaje quién lo envió. Esto suele ser lo mismo que el Fromencabezado, que es de quién es el mensaje. Sin embargo, puede diferir en algunos casos en los que un agente de correo envía mensajes en nombre de otra persona.

El Return-Pathencabezado se utiliza para indicar al destinatario (o al MTA receptor) dónde se enviarán los recibos de no entrega.

Por ejemplo, tome un servidor que permita a los usuarios enviar correo desde una página web. Entonces, sender@yourcompany.comescribe un mensaje y lo envía. El servidor luego envía el mensaje a su destinatario con Fromset to sender@yourcompany.com. El envío SMTP real utiliza diferentes credenciales, algo así mailagent@mywebmail.com. Por lo tanto, el senderencabezado se establece en mailagent@mywebmail.com, para indicar que el Fromencabezado no indica quién envió realmente el mensaje.

En este caso, si el mensaje no se puede enviar, probablemente sea mejor que el agente reciba el informe de no entrega, por Return-Pathlo que también se configurará para mailagent@mywebmail.comque los informes de entrega vayan a él en lugar del remitente.

Si está haciendo exactamente eso, un envío de formulario para enviar un correo electrónico, entonces este es probablemente un paralelo directo con la forma en que configuraría los encabezados.

— Shawn D.
fuente

Además, no tiene que configurar todo. es decir, si deja de lado el remitente y la ruta de retorno, van a la dirección De. Si deja de lado la ruta de retorno, creo que los NDR van al remitente.

— Shawn D.

... Lo cual es una molestia atractiva para los bombarderos de correo. ¡No hagas eso!

— tripleee

¿Entiendo esto bien? Cuando se habla de un formulario web para enviar un correo electrónico, ¿ Senderes la persona que envió el formulario web y Fromel servidor que envió el correo electrónico? ¿O es al revés?

— Ethan Leroy

Imagine algún VIP que tenga un asistente manejando su buzón. Si el asistente está escribiendo un correo electrónico en nombre del VIP, el asistente es el Sender, pero el mensaje es Fromel VIP. Esto es lo que sucede cuando ve un correo electrónico descrito como "Del asistente en nombre de VIP"

— dewin

@ShawnD., ¿Qué pasa si no hay Return-Path? ¿El valor predeterminado es Senderentonces?

— Pacerier

El RFC oficial que define esta especificación se puede encontrar aquí:

http://tools.ietf.org/html/rfc4021#section-2.1.2 (consulte el párrafo 2.1.2. y lo siguiente)

2.1.2. Campo de encabezado: desde

Description:  
    Mailbox of message author  
[...]  
Related information:
    Specifies the author(s) of the message; that is, the mailbox(es)
    of the person(s) or system(s) responsible for the writing of the
    message. Defined as standard by RFC 822.

2.1.3. Campo de encabezado: remitente

Description:  
    Mailbox of message sender  
[...]  
Related information:
    Specifies the mailbox of the agent responsible for the actual
    transmission of the message.  Defined as standard by RFC 822.

2.1.22. Campo de encabezado: ruta de retorno

Description:
    Message return path
[...]  
Related information:
    Return path for message response diagnostics. See also RFC 2821
    [17]. Defined as standard by RFC 822.

— naitsirch
fuente

Gracias por dar el enlace oficial de RFC. Es realmente útil si alguien pregunta: "¿Basado en qué?"

— Bayuah

Esta otra respuesta (de 2011) afirma que el método indicado aquí hace que gmail marque los correos electrónicos como spam. Me pregunto si ese sigue siendo el caso hoy.

— showdev

Actualizado en RFC 5322 tools.ietf.org/html/rfc5322#section-3.6 . ¿Alguien puede decirle a la gente de SMTP RFC que ayudaría si el campo Remitente tiene que coincidir con la dirección De utilizada en el proceso de protocolo de enlace SMTP si se va a utilizar?

— BeowulfNode42

Una actualización menor a esto: un remitente nunca debe establecer el Return-Path:encabezado. No existe un Return-Path:encabezado para un mensaje en tránsito. El encabezado lo establece el MTA que realiza la entrega final, y generalmente se establece en el valor de a 5321.Frommenos que el sistema local necesite algún tipo de enrutamiento peculiar.

Es un malentendido común porque los usuarios rara vez ven un correo electrónico sin un Return-Path:encabezado en sus buzones. Esto se debe a que siempre ven los mensajes entregados, pero un MTA nunca debería ver un Return-Path:encabezado en un mensaje en tránsito. Ver http://tools.ietf.org/html/rfc5321#section-4.4

— cmeid
fuente

Un remitente que utiliza un cliente de correo electrónico no lo configuraría, pero un "remitente" que escribe un guión que envía correos electrónicos puede configurarlo de forma secuencial, por lo que creo que es engañoso decir que un remitente nunca debería configurarlo.

— chiliNUT

Desafortunadamente, Chilinut es realmente inexacto. Una ruta de retorno: encabezado en un mensaje en tránsito se descartará, el MDA (agente de entrega de correo) que realiza la entrega final establecerá la ruta de retorno: encabezado para que coincida con el valor del 5321. el mensaje. Esto se debe a que el sobre se pierde cuando se entrega el mensaje, por lo que el encabezado Return-Path: registra el origen del sobre cuando el MDA recibió el mensaje.

— cmeid

Estoy mirando los encabezados de un mensaje en mi bandeja de entrada en este momento, y tiene una From:dirección y una dirección ( diferente ) Return-Path:, así que no sé a qué se refiere

— chiliNUT

El Return-Path:encabezado refleja el sobre desde, o RFC5321.De la dirección. El From:encabezado refleja el encabezado de, o RFC5322. De la dirección.

— cmeid

Se está convirtiendo en semántica, lo importante (como arriba) es que no se puede establecer un Return-Path:encabezado al enviar un mensaje. Si lo hace, se descartará en tránsito y luego se establecerá en el valor del RFC5321.De la MDA o desde el sobre que realiza la entrega final del mensaje. Básicamente, el Return-Path:encabezado registra el origen del sobre, ya que el sobre se descarta en el momento de la entrega.

— cmeid