Reenvío de correo electrónico

El reenvío de correo electrónico hace referencia a la operación de redireccionamiento de un mensaje de correo electrónico de una dirección de correo electrónico a una o varias direcciones de correo electrónico diferentes.

El término reenvío, se utilizaba para el correo ordinario desde mucho antes de las comunicaciones electrónicas, no tiene un significado técnico específico,^[1] pero implica que el correo electrónico se ha movido "hacia adelante" a un nuevo destino.

El redireccionamiento de correo electrónico también puede redirigir el correo que va a una dirección específica y enviarlo a una o más direcciones. Por el contrario, los correos electrónicos que se dirigen a varias direcciones de correo pueden converger en un misma dirección de correo electrónico gracias al redireccionamiento.

Los usuarios y los administradores de sistemas de correo electrónico utilizan el mismo término cuándo hablan de redireccionamiento basado en servidor y basado en cliente.

Reenvío basado en servidor

El nombre de dominio (la parte que aparece a la derecha del @ en una dirección de correo electrónico ) define los servidor(es)^[2] destino de las direcciones correspondientes. Un dominio también puede definir servidores de respaldo, los cuales no tienen bandeja de entrada y reenvían mensajes sin cambiar ninguna parte de la estructura del correo.^[3] Por el contrario, los servidores primarios pueden entregar un mensaje a la bandeja de entrada de un usuario y / o reenviarlo cambiando algunas direcciones del correo. Los archivos ~/.forward (ver más abajo ) proporcionan un ejemplo típico de reenvío basado en servidor a diferentes destinatarios.

Los administradores de correo electrónico a veces usan el término redirección como sinónimo de reenvío de correo electrónico basado en servidor a diferentes destinatarios. Los ingenieros de protocolo a veces usan el término Mediador para referirse a un servidor de reenvío.^[4]

Debido al spam, cada vez es más difícil reenviar correo de manera confiable a través de diferentes dominios, y algunos recomiendan evitarlo si es posible.^[5]

Usos del reenvío basado en servidor a diferentes destinatarios

Direcciones de roles: info, ventas, administrador, contacto y nombres similares^[6] pueden aparecer a la izquierda de @ en las direcciones de correo electrónico. Una organización puede reenviar mensajes destinados a una función determinada a la dirección de las personas que actualmente desempeñan esa función u oficina.
Direcciones de seudónimo: La mayoría de las instalaciones de alojamiento de nombres de dominio proporcionan servicios para reenviar correo a otra dirección de correo electrónico, como un buzón que proporciona el proveedor de servicios de Internet del usuario; también existen proveedores independientes de servicios de reenvío de correo. Esto permite a los usuarios tener una dirección de correo electrónico que no cambia al cambiar de proveedor de buzón.
Direcciones múltiples o discontinuadas: Cuando los usuarios cambian su dirección de correo electrónico, o tienen varias direcciones, el usuario o un administrador puede configurar el reenvío desde estas direcciones, si aún son válidas, para evitar perder mensajes.

Reenvío versus redistribución

El reenvío de mensajes sencillo cambia el (los) destinatario (s) del correo y deja el campo del remitente del correo intacto. El campo "remitente del correo" no equivale al encabezado "De" que suele mostrar el cliente de correo electrónico, sino que representa un campo utilizado en las primeras etapas del protocolo SMTP y, posteriormente, guardado como el encabezado Return-Path. Este campo contiene la dirección a la que los sistemas de correo deben enviar mensajes de rebote, informando fallos de entrega (o éxito), si los hay.

Por el contrario, el término redistribución a veces puede significar reenviar el mensaje y también reescribir el campo "remitente del correo". Las listas de correo electrónico son un ejemplo típico de este caso. Los autores envían mensajes a un reflector que realiza el reenvío a cada dirección que pertenece a la lista. De esa forma, los mensajes de rebote (que informan de un error al entregar un mensaje a cualquier suscriptor de la lista) no llegarán al autor del mensaje. Sin embargo, las molestas respuestas automáticas de vacaciones mal configuradas sí llegan a los autores.

Por lo general, el reenvío de mensajes hace expansión del alias, mientras que la redistribución de mensajes, también llamado reenvío tout-court,^[1] sirve para listas de correo. Cuando se llevan a cabo modificaciones adicionales al mensaje, de modo que se asemeje bastante a la acción de un agente de usuario de correo que envía un nuevo mensaje, el término reenvío deja de ser el correcto y es más apropiado usar redistribución.

En el marco de políticas del remitente (SPF), el nombre de dominio en el remitente del correo permanece sujeto a restricciones de filtrado. Por lo tanto, SPF generalmente no permite el reenvío de mensajes simples. La redirección intradominio cumple con SPF siempre que los servidores relevantes compartan una configuración consistente. Los servidores de correo que practican el reenvío de mensajes entre dominios pueden romper SPF incluso si no implementan SPF ellos mismos, es decir, no aplican comprobaciones de SPF ni publican registros de SPF.^[7] Sender Rewriting Scheme proporciona un mecanismo de reenvío genérico compatible con SPF.

Reenvío basado en cliente

Reenvío automatizado basado en cliente

El reenvío en el cliente puede realizarse automáticamente mediante un cliente no interactivo, como un agente de recuperación de correo . Aunque el agente de recuperación utiliza un protocolo de cliente, este reenvío se parece al reenvío basado en servidor en el sentido de que mantiene la misma identidad de mensaje. En este tipo de reenvío se pueden dar problemas con los remitentes del correo.^[7]

Reenvío manual basado en cliente

Un usuario final puede reenviar manualmente un mensaje mediante un cliente de correo electrónico . El reenvío en línea cita el mensaje debajo del texto principal del nuevo mensaje y, por lo general, conserva los archivos adjuntos originales, así como una selección de encabezados (por ejemplo, el original "De" y "Responder a" ). Así el recibidor de un mensaje que se ha reenviado usando este método puede responder al mensaje original; la capacidad para hacerlo depende de la presencia de encabezados originales y puede implicar copiar y pegar manualmente las direcciones de destino relevantes.

El reenvío como adjunto prepara un adjunto MIME (de tipo [rfc:822 message/rfc822]) que contiene el mensaje original completo, incluidos todos los encabezados y cualquier adjunto. Una cosa a tener en cuenta es que incluir todos los encabezados revela mucha información sobre el mensaje, como los servidores que lo transmitieron y cualquier etiqueta de cliente agregada al buzón. El destinatario de un mensaje reenviado de esta manera puede abrir el mensaje adjunto y responderlo sin ningún tipo de problema.

Este tipo de reenvío realmente es una redistribución desde el punto de vista del remitente y del destinatario(s) del correo. La identidad del mensaje también cambia.

Desarrollo histórico del reenvío de correo electrónico

RFC 821, Simple Mail Transfer Protocol (protocolo para transferencia simple de correo), de Jonathan B. Postel en 1982, proporcionó una ruta de reenvío para cada destinatario, una lista opcional de hosts y un buzón de destino requerido. Cuando existía la lista de hosts, servía como ruta de origen, lo que indicaba que cada host tenía que transmitir el correo al siguiente host de la lista. De lo contrario, en el caso de información de destino insuficiente pero donde el servidor conocía el destino correcto, podría asumir la responsabilidad de entregar el mensaje.

El concepto en ese momento preveía que los elementos de la ruta de avance (ruta de origen) se trasladaran a la ruta de retorno (remitente del correo) a medida que un mensaje se retransmite de un servidor SMTP a otro. Incluso si el sistema desaconsejaba el uso de enrutamiento de origen,^[8] construir dinámicamente la ruta de retorno implicaba que la información del "remitente del correo" no podía permanecer en su forma original durante el reenvío. Por tanto, RFC 821 no permitía originalmente el reenvío de mensajes sin formato.

La introducción del registro MX^[9] hizo innecesario el enrutamiento de origen. En 1989, RFC 1123 recomendó aceptar el enrutamiento de origen solo para compatibilidad con versiones anteriores. En ese momento, el reenvío de mensajes sin formato^[7] convirtió en la acción recomendada para la expansión del alias. En 2008, RFC 5321 todavía menciona que "los sistemas pueden eliminar la ruta de retorno y reconstruirla según sea necesario", teniendo en cuenta que no hacerlo podría revelar información confidencial inadvertidamente.^[10] En realidad, el reenvío simple de mensajes se puede usar convenientemente para la expansión de alias dentro del mismo servidor o un conjunto de servidores coordinados.

`~/.forward` archivos

La implementación de SMTP que se usaba como referencia a principios de la década de 1980 fue sendmail, que proporcionó archivos ~/.forward, que pueden almacenar las direcciones de correo electrónico de destino para determinados usuarios. Este tipo de reenvío basado en servidor a veces se denomina reenvío de puntos .^[11] Se pueden configurar algunos filtros de programas de correo electrónico para realizar automáticamente acciones de reenvío o respuesta inmediatamente después de recibir un mensaje. Los archivos de reenvío también pueden contener scripts de shell, con el tiempo esto se ha convertido en una fuente de muchos problemas de seguridad. Anteriormente, solo los usuarios de confianza podían utilizar el modificador de línea de comandos para configurar el remitente del sobre, -f arg ; algunos sistemas deshabilitaron esta función por razones de seguridad.^[12]

El correo electrónico es anterior a la formalización de las arquitecturas cliente-servidor en la década de 1990.^[13] Por tanto, la distinción entre cliente y servidor parece necesariamente forzada. La distinción original contrastaba demonios y programas controlados por el usuario que se ejecutan en la misma máquina. El demonio de sendmail solía ejecutarse con privilegios de root para que pudiera hacerse pasar por cualquier usuario cuyo correo tuviera que administrar. Por otro lado, los usuarios pueden acceder a sus propios archivos de correo y archivos de configuración, incluidos ~/.forward . Los programas cliente pueden ayudar a editar los archivos de configuración del servidor de un usuario determinado, lo que provoca cierta confusión en cuanto al papel que desempeña cada programa.

Usuarios virtuales

El término "usuarios virtuales" se refiere a los usuarios de correo electrónico que nunca inician sesión en un sistema de servidor de correo y solo acceden a sus buzones de correo mediante clientes remotos. Un programa de servidor de correo puede funcionar tanto para usuarios virtuales como para usuarios regulares, o puede requerir modificaciones menores para aprovechar el hecho de que los usuarios virtuales comparten con frecuencia la misma identificación del sistema. Esta última circunstancia permite que el programa servidor implemente algunas funciones más fácilmente, ya que no tiene que obedecer las restricciones de acceso al sistema. Se aplican los mismos principios de funcionamiento. Sin embargo, los usuarios virtuales tienen más dificultades para acceder a sus archivos de configuración.

Véase también

Notas

↑ ^a ^b In section 3.9.2 List of RFC 5321, the term forwarding is used ambiguously. It notes that "the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the [Return-Path header]." That wording, new w.r.t. RFC 2821, could be interpreted as the definition of forwarding, if the same term weren't used at the beginning of the same subsection with the opposite meaning. As a contributor to RFC 5321 agreed, Tony Finch (3 de noviembre de 2008). «English terms for forwarded addresses». IETF. Archivado desde el original el 11 de diciembre de 2008. Consultado el 7 de noviembre de 2008. «[forwarding is] a fuzzy (non-technical) term in SMTP».
↑ The primary MX record of the relevant domain usually publishes the name of the mail server.
↑ The envelope of a message is the data transmitted in an SMTP transaction before transmitting the content of the message.
↑ «Mediators», Internet Mail Architecture, sec. 5, doi:10.17487/RFC5598, RFC 5598 .
↑ John Levine (15 de octubre de 2008). «Users Don't Like Forwarded Spam». CircleID. Consultado el 7 de noviembre de 2008.
↑ RFC 2142, "Mailbox Names for Common Services, Roles and Functions", 1997, mentions also marketing, support, abuse, security, webmaster, and more.
↑ ^a ^b ^c Consider the following forward path:
↑ See the note in section 6.2.7 Explicit path specification of RFC 822
↑ MX record has been introduced with RFC 974. See the historical section in MX record#History of fallback to A.
↑ Plain message forwarding may disclose the final destination-address irrespectively of the user's intention. See sections 7.7 Information Disclosure in Message Forwarding, and 4.4 Trace Information in RFC 5321.
↑ «Alias», Problemas de interoperabilidad entre autentiación basada en dominio, informes, y conformidad de mensaje (DMARC) los flujosd de correo indirecto, sec. 3.2.1, doi:10.17487/RFC7960, RFC 7960 .
↑ Hunt, Craig (2002). TCP/IP Network Administration. O'Reilly. p. 606. ISBN 0-596-00334-X. The A 2006 (version 8.708 of 2006) sendmail documentation mentions no restrictions in using the -f switch, and uses the verb set rather than override to describe its action on the envelope sender data.
↑ The book dates in client-server-faqUso incorrecto de la plantilla enlace roto (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). range from the early 1990s. Although remote procedure calls originated in the 1970s, they did not become widely used until networks became quite common.

Datos: Q1725059

[forwarding-1] In section 3.9.2 List of RFC 5321, the term forwarding is used ambiguously. It notes that "the key difference between handling aliases (Section 3.9.1) and forwarding (this subsection) is the change to the [Return-Path header]." That wording, new w.r.t. RFC 2821, could be interpreted as the definition of forwarding, if the same term weren't used at the beginning of the same subsection with the opposite meaning. As a contributor to RFC 5321 agreed, Tony Finch (3 de noviembre de 2008). «English terms for forwarded addresses». IETF. Archivado desde el original el 11 de diciembre de 2008. Consultado el 7 de noviembre de 2008. «[forwarding is] a fuzzy (non-technical) term in SMTP».

[2] The primary MX record of the relevant domain usually publishes the name of the mail server.

[3] The envelope of a message is the data transmitted in an SMTP transaction before transmitting the content of the message.

[4] «Mediators», Internet Mail Architecture, sec. 5, doi:10.17487/RFC5598, RFC 5598 .

[5] John Levine (15 de octubre de 2008). «Users Don't Like Forwarded Spam». CircleID. Consultado el 7 de noviembre de 2008.

[6] RFC 2142, "Mailbox Names for Common Services, Roles and Functions", 1997, mentions also marketing, support, abuse, security, webmaster, and more.

[forward_c_harmful-7] Consider the following forward path:

[8] See the note in section 6.2.7 Explicit path specification of RFC 822

[9] MX record has been introduced with RFC 974. See the historical section in MX record#History of fallback to A.

[10] Plain message forwarding may disclose the final destination-address irrespectively of the user's intention. See sections 7.7 Information Disclosure in Message Forwarding, and 4.4 Trace Information in RFC 5321.

[11] «Alias», Problemas de interoperabilidad entre autentiación basada en dominio, informes, y conformidad de mensaje (DMARC) los flujosd de correo indirecto, sec. 3.2.1, doi:10.17487/RFC7960, RFC 7960 .

[12] Hunt, Craig (2002). TCP/IP Network Administration. O'Reilly. p. 606. ISBN 0-596-00334-X. The A 2006 (version 8.708 of 2006) sendmail documentation mentions no restrictions in using the -f switch, and uses the verb set rather than override to describe its action on the envelope sender data.

[13] The book dates in client-server-faqUso incorrecto de la plantilla enlace roto (enlace roto disponible en Internet Archive; véase el historial, la primera versión y la última). range from the early 1990s. Although remote procedure calls originated in the 1970s, they did not become widely used until networks became quite common.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]