Razones legítimas SMTP "CORREO DESDE:" no coincidirá con el encabezado "Desde:" en DATOS


18

¿Existe alguna razón legítima para que el campo SMTP "CORREO DESDE:" no coincida con el campo "Desde:" en la sección DATOS de un mensaje, además de las listas de correo?

Desde /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

“Pero, para continuar con la metáfora del correo postal, la mayoría de las cartas profesionales contendrán las direcciones del remitente y del destinatario impresas en la carta misma. Esas direcciones no son necesarias para el cartero, sino que son una cortesía para el destinatario. Por lo tanto, es sensato que el correo electrónico funcione de la misma manera ".

El problema con esta línea de lógica reside aquí: "cortesía para el destinatario". Incluir la dirección "De:" en un correo electrónico a través de SMTP no es una cortesía; es obligatorio si el destinatario puede enviar una respuesta.

From: ¿Cómo limitar el encabezado From para que coincida con MAIL FROM en postfix? :

"Pero si realmente quiere asegurarse de From: y MAIL FROM, entonces debe aplicar header_checks para que Return-Path: coincida con From:"

¿Cuáles son las implicaciones de hacer esto? Las listas de correo obviamente serían un problema. ¿Existen otros usos legítimos de la información del encabezado "MAIL FROM:" y "From:"?

Respuestas:


22

Hay muchas razones por las que las direcciones Encabezado y Sobre desde pueden no coincidir. La mayoría se refiere a los procesos automatizados de envío de correo, donde los problemas de entrega deben informarse a una dirección que no sea representativa de quién envió el correo, o de quién fue enviado en nombre de, o a quién debería responderse. Las listas de correo como has señalado son un buen ejemplo.

La razón principal por la que un mensaje enviado desde el cliente de correo de un usuario puede tener direcciones diferentes es el correo reenviado. El contenido del correo debe ser razonablemente fiel al original, pero en caso de errores de entrega, se deben informar al usuario que reenvió el correo electrónico, no al remitente original.

Además del encabezado SMTP, hay una variedad de encabezados MIME que utilizan varios programas para tratar de distinguir entre el remitente original y el remitente intermedio, y / o la dirección preferida para reportar errores. , Errores a, etc., etc., cada uno con una semántica diferente. Algunos de estos tienen soporte de estándares, mientras que muchos más no, pero pueden estar en uso de todos modos. La forma en que se comportan varios programas de correo en la práctica varía considerablemente.

Si una forma de direccionar el correo es aconsejable es una cuestión diferente de si es "legítimo" como usted pregunta. Si está considerando la legitimidad aquí en términos de algo como una política para manejar el spam potencial, entonces no, no creo que pueda hacer una distinción simple de esta manera.

Piense en la firma de correo electrónico DKIM y la autenticación SPF de servidores de correo para dominios de correo electrónico. Si envía mucho correo, puede ser importante poder autenticar su correo de esta manera, y eso puede tener implicaciones para el direccionamiento del correo desde los encabezados, ya que solo puede autenticar el correo relacionado con dominios para los que tiene autoridad .

-

Extendido bajo pedido:

Un encabezado MIME 'Reply-To' dirige a un MUA (Agente de usuario de correo, generalmente el cliente de correo de una persona) para enviar respuestas a una dirección diferente, en lugar de la dirección MIME 'De'. Esto no lo utiliza un MTA (Agente de transporte de correo) para cosas como errores.

Por lo general, un MTA usaría la dirección SMTP Envelope 'MAIL From' para enviar errores a. Se puede reemplazar con un encabezado 'Errores a' de MIME, que es una instrucción MTA. No todos los MTA lo respetarán, por lo que es un mecanismo inferior para configurar la dirección del Sobre SMTP, pero hay muchas circunstancias en las que es posible establecer Encabezados MIME en un mensaje, pero no la dirección Desde del Sobre SMTP. Por ejemplo, el software que se ejecuta en un entorno de alojamiento compartido puede encontrarse en esta situación.

'Remitente' es mucho más ambiguo como una instrucción para los agentes de software, pero indica quién o qué envió el correo electrónico donde es diferente de la dirección De, que es más como a quién se envió el correo en nombre de. Por ejemplo, cuando complete un formulario en línea de correo electrónico para su político, sería muy apropiado que el correo electrónico resultante utilice su correo en el encabezado De, pero tenga una dirección de remitente relacionada con la organización que configuró el formulario.

'Originalmente desde' es utilizado por algún software MUA al reenviar correo, y la dirección del reenviador se usa para el encabezado 'Desde'. Otros MUA dejarán en paz la dirección De y usarán un encabezado 'Reenviar desde'. Si los MUA que reciben estos diversos correos electrónicos de encabezados interpretan los encabezados de manera útil, o incluso los muestran, es bastante variable. Al responder a un correo que se le ha enviado, ¿a quién debe dirigirse la respuesta de forma predeterminada? ¿Quizás sea mejor configurar ese encabezado 'Responder a'?

El comportamiento de los MUA es variable, y está mal definido, aunque parece estar mejorando con el tiempo. Por el contrario, la semántica de la envoltura está mucho más definida. Por lo general, ha habido una fuerte posición de que los MTA nunca deberían preocuparse por los encabezados de MIME, pero a medida que los MTA son cada vez más responsables del contenido del correo (por ejemplo, ver SPF y los estándares emergentes de DMARC), existe una presión para que se degrade la claridad de esa posición. Mecanismos de larga data como Errores-To también han estado en conflicto con la noción de que los MTA no miran el contenido del encabezado, lo cual es parte de por qué esos mecanismos siempre se han aplicado de manera inconsistente. Las filosofías de los autores de software varían.

Puede que le resulte útil revisar http://tools.ietf.org/html/rfc4021#section-2 , pero recuerde que las prácticas reales de la multitud de software de correo varían de formas que no son necesariamente bendecidas por los estándares.

Está bien tratar de llegar a una filosofía clara de cómo crees que debería usarse el correo, pero no esperes que todos los demás hagan las cosas como crees que deberían.


Todavía tengo tiempo para otorgar esta recompensa y estoy interesado en escenarios adicionales que requerirían el uso de los encabezados: `Responder-al, Remitente, Originalmente de, Errores-
a`

Gracias por las adiciones. Espero obtener una comprensión clara de cuáles son los comportamientos esperados de la MTA, frente a cómo se implementan. Además, puede interesarle esto q: acabo de publicar en Sec.StackExchange con respecto a la lista blanca de correo electrónico (similar a BATV) security.stackexchange.com/q/41008/396
goodguys_activate

1
+1, ¿por qué solo 4 votos?
Pacerier

11

El procesamiento automatizado es una gran razón. Desea poder enviar los rebotes / respuestas automáticas / errores para que se procesen por separado, de lo contrario, esos mensajes desaparecerán, se ignorarán o una savia pobre tendrá que cavar a través de ellos. Sí, es posible agregar un encabezado X para el procesamiento, pero la mayor parte del tiempo rebota / etc. no incluirá el correo electrónico original o solo una parte destrozada y no podrá obtener la fuente.

Por ejemplo, digamos que alguien se registra en su sitio web y le envía un correo electrónico diciendo gracias por registrarse. Su MAILFROM y From podrían verse así:

MAIL FROM: <user-signup-123123123@bounces.example.com>
From: Website X <noreply@example.com>

De esta manera, el usuario ve el "amigo de" en el cliente de correo. Pero si el usuario no existe, su MTA enviará el mensaje de devolución a:

user-signup-123123123@bounces.example.com

y un proceso automatizado puede extraer fácilmente el ID de usuario (la parte 123123123) y la parte del sistema que creó el rebote (la parte -signup-) del encabezado y eliminar / marcar fácilmente a ese usuario como deshabilitado.


8

El correo de: en la conversación smtp está diseñado para ser el lugar donde irán los rebotes. El encabezado De: en el cuerpo del mensaje se usa para mostrar al destinatario y como la dirección de respuesta si el encabezado Responder a: no está configurado.

Los correos electrónicos que no deberían generar un rebote deben establecer el remitente vacío en el sobre, por ejemplo, un recibo de devolución generalmente tendrá: mail from:<>con el nombre del usuario en el encabezado from :.

Otra situación es cuando un servidor de correo utiliza BATV para rechazar los rebotes falsificados. El correo de: tendrá el formato prvs=tag-value=mailbox@example.com.


Creo recordar haber visto un encabezado X para devoluciones y NDR. ¿Sabes cuándo y cómo se usa esto?
goodguys_activate

Los encabezados X se agregaron originalmente como un medio de MUA y / o MTA para colocar metadatos personalizados y no se especifican en ningún estándar, aunque algunos se convierten en estándares de facto. Puede estar pensando en el tipo de mime multiparte / informe definido en rfc 6522 que se definió para ayudar al software a clasificar los mensajes que se devuelven automáticamente. Todavía se enviarán con un sobre vacío por correo desde:
Richard Salts

1

A menos que no esté leyendo mis encabezados o la pregunta correctamente, los correos electrónicos de mi BlackBerry se envían desde el servidor BlackBerry y, básicamente, ninguno de los campos coincide. Pequeño porcentaje de usuarios, me doy cuenta. He estado mirando esto recientemente al evaluar mi servidor de correo. A continuación se muestra un correo electrónico anónimo enviado desde mi BlackBerry a mi cuenta de Gmail:

Delivered-To: recipientusername@gmail.com
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <recipientusername@gmail.com>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <recipientusername@gmail.com>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: senderusername@example.com
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <recipientusername@gmail.com>
From: senderusername@example.com
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T

Hay una excelente razón para esto: la reescritura de SPF . Si BlackBerry no estuviera haciendo esto, recibiría muchas más fallas SPF desde su dispositivo.
MikeyB

Es cierto, pero eso se debe a que BlackBerry no usa mi servidor para enviar.
Paul
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.