¿Los servidores SMTP durante la comunicación de servidor (STMP) a servidor (SMTP) generalmente están obligados a copiar MAIL FROM de la sesión cliente-servidor? He comprobado explícitamente que los servidores de algunos proveedores de correo realmente muestran este comportamiento, pero no parece ser un requisito impuesto porhttps://datatracker.ietf.org/doc/html/rfc5321. Además, no sé qué tan popular es esta práctica (si es que no es un estándar).
Actualización para ser más específico: estoy interesado principalmente en el caso de un mensaje de correo electrónico muy habitual, de persona a persona, con dominios en dos servidores diferentes.
Respuesta1
Los servidores están obligados a mantener abierta la ruta de retorno, la forma más sencilla de hacerlo es copiar la MAIL FROM:dirección original y reutilizarla en la transmisión SMTP saliente, pero esta no es la única forma de satisfacer ese requisito.
Generalmente hacen eso, pero algunos servidores toman otras acciones como implementarBATV,SRSo alguna otra forma deVERP.
Como tal, es seguro esperar que un correo electrónico dirigido al supuesto remitente llegue a la entidad responsable de crear el mensaje, pero posiblemente a través de uno o más intermediarios que restablezcan la dirección del remitente SMTP anterior.
Respuesta2
ElRFC 5321, 3.3dice para qué MAIL FROM:<reverse-path>sirve:
La
<reverse-path>parte del primer o único argumento contiene el buzón de origen (entre corchetes "<" y ">"), que se puede utilizar para informar errores (consulteSección 4.2para una discusión sobre el informe de errores).
Elcampos de origenen los encabezados del formato de mensajes de Internet (RFC 5322, 3.6.2) tienen propósitos más específicos para distinguir al autor ( From:) deel agente responsable de la transmisión real del mensaje( Sender):
Por ejemplo, si una secretaria enviara un mensaje para otra persona, el buzón de la secretaria aparecería en el
Sender:campo " " y el buzón del autor real aparecería en elFrom:campo " ".
El RFC 5321remitente del sobretiene una finalidad meramente técnica. Es típico enreenvío de correoylista de correoescenarios para reescribir el MAIL FROMpara que coincida con el dominio/servidor de reenvío o el operador de la lista de correo. Esto tiene dos beneficios:
- Los informes de error llegarán al operador de la lista de correo, quien deberá encargarse de eliminar las direcciones erróneas de la lista.
- Reescribir el remitente del sobre no rompe la política SPF del dominio original (Shevek (2004):El esquema de reescritura del remitente).
Por otra parte, tales prácticas van ligeramente en contraRFC 5321, 3.7.5:
3.7.5. Sobres en puerta de enlace
De manera similar, al reenviar un mensaje desde otro entorno a Internet, la puerta de enlace DEBE configurar la ruta de retorno del sobre de acuerdo con una dirección de devolución de mensaje de error, si la proporciona el entorno externo. Si el entorno externo no tiene un concepto equivalente, la puerta de enlace debe seleccionar y utilizar la mejor aproximación, con la dirección del originador del mensaje como último recurso predeterminado.
No veo esto como un problema, porque el protocolo SMTP no se ha actualizado (a excepción de los códigos de respuesta SMTP 521 y 556,RFC 7504) desde 2008, pero las prácticas, incluida la prevención de la falsificación de correos electrónicos, han evolucionado desde entonces.
Respuesta3
MAIL FROM:<reverse-path>Como sugiere el nombre del parámetro, esto se usa si el servidor necesita "devolver" el correo electrónico, como por ejemplo un error u otros problemas, y no es necesario que sea el mismo que el remitente del correo electrónico original.
Muchos servidores validan este campo y lo utilizan para spam, pero no hay requisitos para ello.