El reenvío de correo electrónico se refiere genéricamente a la operación de reenviar un mensaje de correo electrónico 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 determinada dirección y enviarlo a una o más direcciones. Viceversa, los elementos de correo electrónico que van a varias direcciones diferentes pueden converger a través del reenvío para terminar en una sola dirección de la bandeja de entrada. [ aclaración necesaria ]
Los usuarios de correo electrónico y los administradores de sistemas de correo electrónico utilizan el mismo término cuando se habla de reenvío basado en servidor y en cliente .
Reenvío basado en servidor
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 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 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
- información , ventas , administrador de correo 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 la persona o personas que actualmente desempeñan esa función u oficina.
- Direcciones de seudónimo
- La mayoría de las instalaciones de hospedaje de nombres de dominio brindan servicios para reenviar correo a otra dirección de correo electrónico, como un buzón en 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 si cambian 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, a una única actual, para evitar perder mensajes.
Reenvío versus reenvío
El reenvío de mensajes sencillos cambia el (los) destinatario (s) 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, 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 el error de entrega (o el éxito), 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 lista. De esa forma, 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 de un 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 hace expansión de alias, mientras que el reenvío de mensajes adecuado, 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 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ítica. Por lo tanto, SPF generalmente no permite el reenvío de mensajes sin formato. 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] El sistema de reescritura del remitente proporciona un mecanismo de reenvío genérico compatible con SPF.
Reenvío basado en el cliente
Reenvío automatizado basado en el cliente
El reenvío de clientes 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 del servidor en el sentido de que mantiene la misma identidad de mensaje. Se aplican preocupaciones sobre el remitente del sobre. [7]
Reenvío manual basado en el 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 seleccionados (por ejemplo, el original De y Responder a ). El destinatario de un mensaje reenviado de esta manera aún puede para 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 message / rfc822 ) que contiene el mensaje original completo, incluidos todos los encabezados y cualquier 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 que realmente constituye un reenvío desde el punto de vista del sobre-remitente y del destinatario (s). La identidad del mensaje también cambia.
Desarrollo histórico del reenvío de correo electrónico
RFC 821, Simple Mail Transfer Protocol , de Jonathan B. Postel en 1982, proporcionó una ruta de reenvío para cada destinatario, en forma de, por ejemplo, @USC-ISIE.ARPA, @USC-ISIF.ARPA: [email protected]
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, lo que indica 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 respondiendo de la siguiente manera:
S: RCPT PARA:@usc-isi.arpa> R: 251 Usuario no local; lo reenviará a @usc-isif.arpa>
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 sobre) a medida que un mensaje se retransmitía 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 sobre" no podía permanecer en su forma original durante el reenvío. Por lo 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] 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 reconstruir [la] según sea necesario", teniendo en cuenta que no hacerlo podría revelar inadvertidamente información confidencial. [10] En realidad, el reenvío simple de mensajes se puede utilizar convenientemente para la expansión de alias dentro del mismo servidor o en un conjunto de servidores coordinados.
~/.forward
archivos
La implementación de SMTP de referencia a principios de la década de 1980 era sendmail , que proporcionaba ~/.forward
archivos 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 por 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. Los archivos de reenvío también pueden contener secuencias de comandos de shell , que se han convertido en una fuente de muchos problemas de seguridad. Anteriormente, solo los usuarios de confianza podían utilizar el conmutador de línea de comandos para configurar el remitente del sobre ; algunos sistemas deshabilitaron esta función por razones de seguridad. [12]-f arg
El correo electrónico es anterior a la formalización de las arquitecturas cliente-servidor en la década de 1990. [13] Por lo 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 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 archivos de configuración, incluidos . Los programas cliente pueden ayudar a editar los archivos de configuración del servidor de un usuario determinado, lo que genera cierta confusión en cuanto a la función que desempeña cada programa.~/.forward
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 utilizando 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, para bien o para mal.
Productos comerciales que facilitan el reenvío de correo
- https://forwardemail.net
- https://emailforward.mx
- https://improvmx.com
- https://grouplist.io/
- http://forwardmx.io/
Ver también
- Correo electrónico en cadena
- Lista de correo electrónico
- Alias de correo electrónico
- Carta de correo electrónico
- Abreviaturas del asunto del correo electrónico
- Correo no deseado
- Agente de usuario de correo (MUA) también conocido como cliente de correo electrónico
- Agente de transferencia de mensajes (MTA)
- Tormenta de correo electrónico
Notas
- ^ a b En la sección 3.9.2 Lista de RFC 5321, el término reenvío se utiliza de forma ambigua. Señala que " la diferencia clave entre el manejo de alias (Sección 3.9.1) y el reenvío (esta subsección) es el cambio al [ encabezado de la ruta de retorno ] ". Esa redacción, nueva wrt RFC 2821, podría interpretarse como la definición de reenvío , si no se usara el mismo término al principio de la misma subsección con el significado opuesto. Como colaborador de RFC 5321 estuvo de acuerdo, Tony Finch (2008-11-03). "Términos en inglés para direcciones reenviadas" . IETF . Archivado desde el original el 11 de diciembre de 2008 . Consultado el 7 de noviembre de 2008 .
[ reenvío es] un término impreciso (no técnico) en SMTP
- ^ El registro MX principaldel dominio relevante generalmente publica el nombre del servidor de correo . De lo contrario, el nombre de dominio debe tener una dirección IP .
- ^ El sobre de un mensaje son los datos transmitidos en unatransacción SMTP antes de transmitir el contenido del mensaje. El sobre se pierde cuando se entrega el mensaje, aunque el servidor receptor puede guardar algunos de sus campos en los encabezados del mensaje. En particular, el sobre contiene la ruta de retorno (también conocida como dirección de rebote ,argumento MAIL FROM , mailfrom o mfrom ) y uno o más destinatarios (incluidos Cco ).
- ^ Dave Crocker (julio de 2009). "Mediadores" . Arquitectura de correo de Internet . IETF . segundo. 5. doi : 10.17487 / RFC5598 . RFC 5598 . Consultado el 19 de marzo de 2013 .
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 disponible para los MTA.
- ^ John Levine (15 de octubre de 2008). "A los usuarios no les gusta el spam reenviado" . CircleID . Consultado el 7 de noviembre de 2008 .
- ^ RFC 2142, "Nombres de buzones para servicios comunes, roles y funciones" , 1997, menciona también marketing , soporte , abuso , seguridad , webmaster y más.
- ^ a b c Considere la siguiente ruta hacia adelante:
- ^ Consulte la nota en la sección 6.2.7 Especificación de ruta explícita de RFC 822
- ^ Registro MX se ha introducido con RFC 974. Véase la sección histórica de MX registro # Historia de repliegue a A .
- ^ El reenvío de mensajes sencillos puede revelar la dirección de destino final independientemente de la intención del usuario. Consulte las secciones 7.7 Divulgación de información en el reenvío de mensajes y 4.4 Información de seguimiento en RFC 5321.
- ^ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (Septiembre de 2016). "Alias" . Problemas de interoperabilidad entre autenticación, informes y conformidad de mensajes basados en dominios (DMARC) y flujos de correo electrónico indirecto . IETF . segundo. 3.2.1. doi : 10.17487 / RFC7960 . RFC 7960 . Consultado el 14 de marzo de 2017 .
- ^ Hunt, Craig (2002). Administración de red TCP / IP . O'Reilly. pag. 606. ISBN 0-596-00334-X. La corriente[actualizar](versión 8.708 de 2006) la documentación de sendmail no menciona restricciones en el uso del
-f
conmutador y usa el verbo set en lugar de override para describir su acción en los datos del remitente del sobre. - ^ Las fechas del libro en client-server-faq [ enlace muerto permanente ] van desde principios de la década de 1990. Aunque las llamadas a procedimientos remotos se originaron en la década de 1970, no se utilizaron ampliamente hasta que las redes se volvieron bastante comunes.