El reenvío de correo electrónico se refiere genéricamente a la operación de reenviar un correo electrónico previamente entregado a una dirección de correo electrónico a una o más direcciones de correo electrónico diferentes.
El término reenvío , utilizado para el correo 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 reenvío de correo electrónico también puede redirigir el correo que va a una dirección determinada y enviarlo a una o más direcciones. Viceversa, los elementos de correo electrónico que van a varias direcciones diferentes pueden converger mediante el reenvío y terminar en una única bandeja de entrada de dirección. [ se necesita aclaración ]
Los usuarios de correo electrónico y los administradores de sistemas de correo electrónico utilizan el mismo término cuando hablan de reenvío tanto basado en servidor como basado en cliente.
El nombre de dominio (la parte que aparece a la derecha de @ en una dirección de correo electrónico ) define los servidores de destino [2] para la clase de direcciones correspondiente. Un dominio también puede definir servidores de respaldo ; no tienen buzones y reenvían mensajes sin cambiar ninguna parte de sus sobres. [3] Por el contrario, los servidores primarios pueden entregar un mensaje al buzón de un usuario y/o reenviarlo cambiando algunas direcciones de sobre. 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 utilizan el término redirección como sinónimo de reenvío de correo electrónico basado en servidor a diferentes destinatarios. Los ingenieros de protocolos a veces utilizan 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 entre diferentes dominios y algunos recomiendan evitarlo si es posible. [5]
El reenvío de mensajes simple cambia los destinatarios del sobre y deja intacto el campo del remitente del sobre . El campo "remitente del sobre" no equivale al encabezado De que generalmente muestra el software del cliente de correo electrónico: representa un campo utilizado en las primeras etapas del protocolo SMTP y posteriormente guardado como el encabezado de la ruta de retorno . Este campo contiene la dirección a la que los sistemas de correo deben enviar mensajes de rebote (informando de fallo (o éxito) en la entrega), si corresponde.
Por el contrario, los términos reenvío o redistribución a veces pueden significar reenviar el mensaje y también reescribir el campo "remitente del sobre". Las listas de correo electrónico proporcionan un ejemplo típico. Los autores envían mensajes a un reflector que realiza el reenvío a cada dirección de la lista. De esa manera, los mensajes rebotados (que informan de una falla en la entrega de 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 llegan a los autores.
Normalmente, el reenvío de mensajes simple realiza una expansión de alias, mientras que el reenvío de mensajes adecuado, también denominado reenvío tout-court [1], sirve para listas de correo. Cuando se llevan a cabo modificaciones adicionales al mensaje, para que se parezca más a la acción de un agente de usuario de correo que envía un nuevo mensaje, el término reenvío se vuelve engañoso y el reenvío parece más apropiado.
En el Marco de políticas del remitente (SPF), el nombre de dominio en el remitente del sobre permanece sujeto a restricciones de políticas. Por lo tanto, SPF generalmente no permite el reenvío de mensajes simples. En caso de reenvío, el correo electrónico se envía desde el servidor de reenvío, que no está autorizado a enviar correos electrónicos para el dominio del remitente original. Entonces el SPF fracasará. [7] La redirección dentro del dominio 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 el SPF incluso si no lo implementan ellos mismos, es decir, no aplican comprobaciones de SPF ni publican registros de SPF. [8] El esquema de reescritura del remitente proporciona un mecanismo de reenvío genérico compatible con SPF.
El reenvío de clientes puede realizarse automáticamente utilizando 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 de servidor en que mantiene la misma identidad del mensaje. Se aplican inquietudes sobre el remitente del sobre. [8]
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 seleccionados (por ejemplo, el De y el Responder a originales ). El destinatario de un mensaje reenviado de esta manera aún puede poder responder al mensaje original; la capacidad de hacerlo depende de la presencia de encabezados originales y puede implicar copiar y pegar manualmente las direcciones de destino relevantes.
El reenvío como archivo adjunto prepara un archivo adjunto MIME (de tipo message/rfc822 ) que contiene el mensaje original completo, incluidos todos los encabezados y cualquier archivo adjunto. Tenga en cuenta 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 problemas.
Este tipo de reenvío constituye en realidad un reenvío desde el punto de vista del remitente del sobre y del destinatario. La identidad del mensaje también cambia.
RFC 821, Protocolo simple de transferencia de correo , de Jonathan B. Postel en 1982, proporcionó una ruta de avance para cada destinatario, en la forma de, por ejemplo, @USC-ISIE.ARPA, @USC-ISIF.ARPA: [email protected]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 que la información de destino sea insuficiente pero el servidor conozca el destino correcto, podría asumir la responsabilidad de entregar el mensaje respondiendo de la siguiente manera:
S: RCPT A: <[email protected]> R: 251 Usuario no local; reenviará a < [email protected]> El concepto en ese momento preveía que los elementos de la ruta de ida (ruta de origen) se movían a la ruta de retorno (remitente del sobre) a medida que un mensaje se transmitía de un servidor SMTP a otro. Incluso si el sistema desalentara el uso del enrutamiento de origen, [9] construir dinámicamente la ruta de retorno implicaba que la información del "remitente del sobre" no podía permanecer en su forma original durante el reenvío. Por tanto, RFC 821 originalmente no permitía el reenvío de mensajes simple.
La introducción del registro MX [10] hizo innecesario el enrutamiento de origen. En 1989, RFC 1123 recomendó aceptar el enrutamiento de origen solo por compatibilidad con versiones anteriores. En ese momento, el reenvío simple de mensajes [8] se convirtió en la acción recomendada para la expansión de 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 sin darse cuenta. [11] En realidad, el reenvío de mensajes simple se puede utilizar convenientemente para la expansión de alias dentro del mismo servidor o en un conjunto de servidores coordinados.
La implementación SMTP de referencia a principios de la década de 1980 era sendmail , que proporcionaba ~/.forwardarchivos que podían almacenar las direcciones de correo electrónico de destino para usuarios determinados. Este tipo de reenvío basado en servidor a veces se denomina reenvío de puntos . [12] 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 la recepción. Los archivos de reenvío también pueden contener scripts de shell , que se han convertido en una fuente de muchos problemas de seguridad. Anteriormente, sólo los usuarios de confianza podían utilizar el modificador de línea de comandos para configurar el remitente del sobre ; Algunos sistemas desactivaron esta función por razones de seguridad. [13]-f arg
El correo electrónico es anterior a la formalización de las arquitecturas cliente-servidor en la década de 1990. [14]
Por lo tanto, la distinción entre cliente y servidor parece necesariamente forzada. La distinción original contrastaba los demonios y los programas controlados por el usuario que se ejecutaban en la misma máquina. El demonio sendmail solía ejecutarse con privilegios de root para poder hacerse pasar por cualquier usuario cuyo correo tuviera que administrar. Por otro lado, los usuarios pueden acceder a sus propios archivos de correo y de configuración individuales, incluidos . Los programas cliente pueden ayudar a editar los archivos de configuración del servidor de un usuario determinado, provocando así cierta confusión sobre el papel que desempeña cada programa.~/.forward
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 sólo acceden a sus buzones mediante clientes remotos. Un programa de servidor de correo puede funcionar tanto para usuarios virtuales como regulares, o puede requerir modificaciones menores para aprovechar el hecho de que los usuarios virtuales frecuentemente comparten la misma identificación del sistema . Esta última circunstancia permite que el programa servidor implemente algunas características más fácilmente, ya que no tiene que obedecer restricciones de acceso al sistema. Se aplican los mismos principios de operaciones. Sin embargo, los usuarios virtuales tienen más dificultades para acceder a sus archivos de configuración, para bien o para mal.
[ reenvío es] un término confuso (no técnico) en SMTP
Un Mediador reenvía un mensaje a través de un proceso de reenvío.
El Mediador comparte algunas funciones con la retransmisión básica del MTA, pero tiene mayor flexibilidad tanto en el direccionamiento como en el contenido que la disponible para los MTA.
-fconmutador y utiliza el verbo set en lugar de override para describir su acción en los datos del remitente del sobre.