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 diferentes. A la inversa, los elementos de correo electrónico que van a varias direcciones diferentes pueden converger mediante el reenvío para terminar en una única bandeja de entrada de la dirección. [ Aclaración necesaria ]
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 basado en servidor y basado en cliente.
El nombre de dominio (la parte que aparece a la derecha de @ en una dirección de correo electrónico ) define el servidor o servidores de destino [2] para la clase de direcciones correspondiente. Un dominio también puede definir servidores de respaldo ; no tienen buzones de correo 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 correo de un usuario y/o reenviarlo cambiando algunas direcciones de sobre. Los archivos ~/.forward (ver a continuación) 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 , resulta cada vez más difícil reenviar correo de forma confiable entre diferentes dominios, y algunos recomiendan evitarlo siempre que sea posible. [5]
El reenvío de mensajes simple cambia el destinatario del sobre y deja intacto el campo del remitente del sobre . El campo "remitente del sobre" no equivale al encabezado " De " que suele mostrar el software de cliente de correo electrónico: representa un campo utilizado en las primeras etapas del protocolo SMTP y que posteriormente se guarda como encabezado de ruta de retorno . Este campo contiene la dirección a la que los sistemas de correo deben enviar los mensajes de rebote (para informar sobre errores de entrega o entregas exitosas), si los hubiera.
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 un error 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 sí llegan a los autores.
Por lo general, el reenvío de mensajes simple se encarga de la expansión de alias, mientras que el reenvío de mensajes propiamente dicho, también llamado reenvío tout-court [1], se utiliza para listas de correo. Cuando se realizan modificaciones adicionales al mensaje, de modo 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 Sender Policy Framework (SPF), el nombre de dominio en el remitente del sobre sigue sujeto a restricciones de política. 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. Por lo tanto, el SPF fallará. [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 SPF incluso si no implementan SPF ellos mismos, es decir, no aplican verificaciones SPF ni publican registros SPF. [8] El Sender Rewriting Scheme proporciona un mecanismo de reenvío genérico compatible con SPF.
El reenvío de cliente 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 el sentido de que mantiene la misma identidad del mensaje. Se aplican las preocupaciones sobre el remitente del sobre. [8]
Un usuario final puede reenviar un mensaje manualmente 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 Responder originales ). El destinatario de un mensaje reenviado de esta manera aún puede responder al mensaje original; la capacidad para hacerlo depende de la presencia de los 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 y del destinatario. La identidad del mensaje también cambia.
El RFC 821, Simple Mail Transfer Protocol (Protocolo simple de transferencia de correo) , de Jonathan B. Postel en 1982, preveía una ruta de reenvío para cada destinatario, en forma, por ejemplo, @USC-ISIE.ARPA, @USC-ISIF.ARPA: [email protected]de una lista opcional de hosts y un buzón de destino obligatorio. Cuando existía la lista de hosts, servía como ruta de origen, indicando que cada host tenía que retransmitir el correo al siguiente host de la lista. De lo contrario, en caso de que no hubiera suficiente información sobre el destino pero el servidor conociera el destino correcto, podía asumir la responsabilidad de entregar el mensaje respondiendo de la siguiente manera:
S: RCPT PARA: <[email protected]> R: 251 Usuario no local; reenviará a <[email protected] > El concepto de aquel momento preveía que los elementos de la ruta de ida (ruta de origen) se desplazaran hacia la ruta de retorno (remitente del sobre) a medida que un mensaje se retransmitía de un servidor SMTP a otro. Aunque el sistema desaconsejaba el uso del enrutamiento de origen, [9] la construcción dinámica de 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 ello, la RFC 821 no permitía originalmente el reenvío de mensajes sin formato.
La introducción del registro MX [10] hizo innecesario el enrutamiento de origen. En 1989, la RFC 1123 recomendó aceptar el enrutamiento de origen solo por compatibilidad con versiones anteriores. En ese momento, el reenvío de mensajes simple [8] se convirtió en la acción recomendada para la expansión de alias. En 2008, la 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. [11] En realidad, el reenvío de mensajes simple se puede utilizar convenientemente para la expansión de alias dentro del mismo servidor o un conjunto de servidores coordinados.
La implementación de referencia de SMTP a principios de los años 1980 fue 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 que realicen automáticamente acciones de reenvío o respuesta inmediatamente después de recibirlos. 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, solo los usuarios de confianza podían utilizar el modificador de línea de comandos para configurar el remitente del sobre; algunos sistemas deshabilitaban 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 a los daemons y a los programas controlados por el usuario que se ejecutaban en la misma máquina. El daemon sendmail solía ejecutarse con privilegios de root , por lo que podía 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 individuales, incluidos . Los programas cliente pueden ayudar a editar los archivos de configuración del servidor de un usuario determinado, lo que causa cierta confusión en cuanto a qué papel 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 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 normales, o puede requerir modificaciones menores para aprovechar el hecho de que los usuarios virtuales comparten con frecuencia el mismo identificador de sistema . Esta última circunstancia permite que el programa de servidor implemente algunas funciones con mayor facilidad, ya que no tiene que obedecer las 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 difuso (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 de MTA, pero tiene mayor flexibilidad tanto en el direccionamiento como en el contenido que la que tienen los MTA.
-fconmutador y utiliza el verbo set en lugar de override para describir su acción sobre los datos del remitente del sobre.