Reenvío de correo electrónico
Mecanismo por el cual un servidor de correo envía los correos electrónicos de uno de sus usuarios a otra dirección

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.

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 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]

Usos del reenvío basado en servidor a diferentes destinatarios

Direcciones de roles
Los nombres info , sales , postmaster y similares [6] pueden aparecer a la izquierda de @ en las direcciones de correo electrónico. Una organización puede reenviar mensajes destinados a un rol determinado a la dirección de la(s) persona(s) que actualmente se desempeñan en ese rol u oficina.
Direcciones seudónimas
La mayoría de los servicios de alojamiento de nombres de dominio ofrecen la posibilidad de reenviar correo a otra dirección de correo electrónico, como un buzón de correo del 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 de correo.
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, con el fin de evitar la pérdida de mensajes.

Reenvío versus reenvío

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 éxito), 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 permanece 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.

Reenvío basado en el cliente

Reenvío automatizado basado en el cliente

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]

Reenvío manual basado en el cliente

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.

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

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.

~/.forwardarchivos

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

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 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.

Véase también

Notas

  1. ^ ab En la sección 3.9.2 Lista de RFC 5321, el término reenvío se utiliza de forma ambigua. Se 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 en el encabezado [ Return-Path ] ". Esa redacción, nueva con respecto a RFC 2821, podría interpretarse como la definición de reenvío , si no se utilizara el mismo término al comienzo de la misma subsección con el significado opuesto. Como coincidió un colaborador de RFC 5321, Tony Finch (2008-11-03). "Términos en inglés para direcciones reenviadas". IETF . Archivado desde el original el 2008-12-11 . Consultado el 2008-11-07 . [ reenvío es] un término difuso (no técnico) en SMTP
  2. ^ El registro MX principal del dominio correspondiente suele publicar el nombre del servidor de correo . De lo contrario, el nombre de dominio debe tener una dirección IP .
  3. ^ El sobre de un mensaje son los datos transmitidos en una transacció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 los de Bcc ).
  4. ^ Dave Crocker (julio de 2009). "Mediadores". Arquitectura de correo de Internet. IETF . sec. 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 que tienen los MTA.
  5. ^ John Levine (15 de octubre de 2008). "A los usuarios no les gusta el spam reenviado". CircleID . Consultado el 7 de noviembre de 2008 .
  6. ^ RFC 2142, "Nombres de buzones de correo para servicios, roles y funciones comunes" , 1997, menciona también marketing , soporte , abuso , seguridad , webmaster y más.
  7. ^ "¿Cómo afecta el reenvío de correo electrónico al resultado de la autenticación?". ProDMARC . 6 de enero de 2023 . Consultado el 16 de marzo de 2023 .
  8. ^ abc Consideremos la siguiente ruta hacia adelante:
    A ⟶ B ⟶ do {\displaystyle {\ce {\mathit {A->B->C}}}}
    El dominio B no debe reenviar directamente un mensaje del dominio A al dominio C , a menos que controle la política de A o el filtrado de C. De hecho, si A publica una política SPF que impide que B utilice el nombre de A y C aplica la comprobación de políticas del remitente, C puede rechazar el mensaje de acuerdo con RFC 7208. En otras palabras, no se puede distinguir formalmente el reenvío directo de mensajes del abuso ilegal de nombres de dominio.
  9. ^ Consulte la nota en la sección 6.2.7 Especificación de ruta explícita del RFC 822
  10. ^ El registro MX se introdujo con RFC 974. Consulte la sección histórica en Registro MX#Historial de respaldo a A .
  11. ^ El reenvío de mensajes simples 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 Reenvío de mensajes y 4.4 Información de seguimiento en RFC 5321.
  12. ^ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (septiembre de 2016). "Alias". Problemas de interoperabilidad entre la autenticación, los informes y la conformidad de mensajes basados ​​en dominios (DMARC) y los flujos de correo electrónico indirectos. IETF . sec. 3.2.1. doi : 10.17487/RFC7960 . RFC 7960 . Consultado el 14 de marzo de 2017 .
  13. ^ Hunt, Craig (2002). Administración de redes TCP/IP . O'Reilly. pág. 606. ISBN 0-596-00334-X.La [actualizar]documentación actual de sendmail (versión 8.708 de 2006) no menciona restricciones en el uso del -fconmutador y utiliza el verbo set en lugar de override para describir su acción sobre los datos del remitente del sobre.
  14. ^ Las fechas del libro en client-server-faq [ enlace muerto permanente ] se remontan a principios de la década de 1990. Aunque las llamadas a procedimientos remotos se originaron en la década de 1970, no se empezaron a utilizar ampliamente hasta que las redes se volvieron bastante comunes.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Reenvío_de_correo_electrónico&oldid=1227592021"