Hispanopedia Wiki
Articulo de referencia

Reenvío de correo electrónico

El reenvío de correo electrónico se refiere, en términos generales, a la operación de reenviar un correo electrónico previamente entregado a una dirección de correo electrónico ...

Hispanopedia WikiContenido en espanolLectura gratuita

El reenvío de correo electrónico se refiere, en términos generales, 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 permite redirigir los mensajes dirigidos a una dirección específica a una o más direcciones. Del mismo modo, los correos electrónicos destinados a varias direcciones diferentes pueden converger mediante el reenvío para terminar en la bandeja de entrada de una sola dirección.

Los usuarios de correo electrónico y los administradores de sistemas de correo electrónico utilizan el mismo término al hablar tanto del reenvío basado en servidor como del reenvío 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/ los servidor/es de destino [ 2 ] para la clase de direcciones correspondiente. Un dominio también puede definir servidores de respaldo ; estos no tienen buzones de correo y reenvían mensajes sin modificar ninguna parte de sus sobres. [ 3 ] Por el contrario, los servidores principales pueden entregar un mensaje al buzón de correo de un usuario y/o reenviarlo modificando algunas direcciones de sobre. Los archivos ~/.forward (véase 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 protocolo 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 forma fiable entre diferentes dominios, y algunos recomiendan evitarlo en la medida de lo 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 desempeñan ese rol u oficina.
Direcciones con seudónimos
La mayoría de los proveedores de alojamiento de nombres de dominio ofrecen la opción de reenviar correos electrónicos a otra dirección, 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 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 pueden configurar el reenvío de estos correos, si siguen siendo válidos, a una única dirección actual, para evitar la pérdida de mensajes.

Reenvío versus reenvío

El reenvío simple de mensajes modifica el destinatario o destinatarios del sobre, pero deja intacto el campo del remitente . Este campo no se corresponde con el encabezado "De" que suele mostrar el software cliente de correo electrónico: representa un campo utilizado en las primeras etapas del protocolo SMTP y que posteriormente se guarda como encabezado Return-Path . Este campo contiene la dirección a la que los sistemas de correo deben enviar mensajes de error (si los hubiera), indicando si la entrega fue exitosa o fallida.

Por el contrario, los términos reenvío o redistribución a veces implican volver a enviar el mensaje y también modificar el campo "remitente del sobre". Las listas de correo electrónico son un ejemplo típico. Los autores envían mensajes a un servidor que los reenvía a cada dirección de la lista. De esta forma, los mensajes de error (que indican un fallo en la entrega del mensaje a cualquier suscriptor) no llegan al autor. Sin embargo, las molestas respuestas automáticas de vacaciones mal configuradas sí llegan a los autores.

Por lo general, el reenvío simple de mensajes realiza la expansión de alias, mientras que el reenvío propiamente dicho, también llamado reenvío en general [ 1 ], se utiliza para listas de correo. Cuando se realizan modificaciones adicionales al mensaje, de manera que se asemeje más a la acción de un agente de usuario de correo que envía un nuevo mensaje, el término reenvío resulta engañoso y reenviar 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, 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 comprobaciones de SPF ni publican registros de SPF. [ 8 ] 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 del 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 asemeja al reenvío del servidor, ya que mantiene la misma identidad del mensaje. Se aplican consideraciones sobre el remitente del sobre. [ 8 ]

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 muestra el mensaje original entre comillas 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 remitente y el destinatario originales ) . El destinatario de un mensaje reenviado de esta manera aún puede responder al mensaje original; la posibilidad de hacerlo depende de la presencia de los encabezados originales y puede implicar copiar y pegar manualmente las direcciones de correo electrónico correspondientes.

El reenvío como archivo adjunto genera un archivo adjunto MIME (de tipo message/rfc822 ) que contiene el mensaje original completo, incluyendo 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 añadida al buzón. El destinatario de un mensaje reenviado de esta manera podría abrir el mensaje adjunto y responder sin problemas.

Este tipo de reenvío constituye, en realidad, un reenvío de correo desde el punto de vista del remitente y del destinatario o destinatarios. La identidad del mensaje también cambia.

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

El RFC 821, Protocolo simple de transferencia de correo , de Jonathan B. Postel en 1982, proporcionaba una ruta de reenvío para cada destinatario, en forma de, por ejemplo, @USC-ISIE.ARPA, @USC-ISIF.ARPA: Q-Smith@ISI-VAXA.ARPAuna lista opcional de hosts y un buzón de correo de destino obligatorio. Cuando existía la lista de hosts, servía como ruta de origen, indicando que cada host debía reenviar el correo al siguiente host de la lista. De lo contrario, en caso de información de destino insuficiente, pero cuando el servidor conocía el destino correcto, podía asumir la responsabilidad de entregar el mensaje respondiendo de la siguiente manera:

S: RCPT TO: <Postel@USC-ISI.ARPA> R: 251 Usuario no local; se reenviará a <Postel@USC-ISIF.ARPA>

En aquel entonces, el concepto contemplaba que los elementos de la ruta de reenvío (ruta de origen) se desplazaran hacia la ruta de retorno (remitente del sobre) a medida que un mensaje se transmitía de un servidor SMTP a otro. Si bien 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 lo tanto, la RFC 821 no permitía originalmente el reenvío simple de mensajes.

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 para 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 inadvertidamente información sensible. [ 11 ] De hecho, el reenvío de mensajes simple se puede usar convenientemente para la expansión de alias dentro del mismo servidor o un conjunto de servidores coordinados.

~/.forwardarchivos

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 específicos. Este tipo de reenvío basado en servidor a veces se denomina reenvío por punto . [ 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 deshabilitaron 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 suplantar a cualquier usuario cuyo correo tuviera que gestionar. Por otro lado, los usuarios pueden acceder a sus propios archivos de correo y archivos de configuración, incluidos los programas cliente. Estos pueden ayudar a editar los archivos de configuración del servidor de un usuario determinado, lo que genera cierta confusión sobre el papel 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 servidor de correo y solo acceden a sus buzones mediante clientes remotos. Un programa de servidor de correo puede funcionar tanto para usuarios virtuales como para usuarios regulares, o puede requerir pequeñas modificaciones para aprovechar que los usuarios virtuales suelen compartir el mismo ID de sistema . Esta última circunstancia permite al programa implementar algunas funciones con mayor facilidad, ya que no tiene que cumplir con 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.

Véase también

Notas

  1. 1 2 En la sección 3.9.2 Lista de RFC 5321, el término reenvío se usa 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 el mismo término no se usara al principio de la misma subsección con el significado opuesto. Como coincidió Tony Finch (2008-11-03) , colaborador de RFC 5321. "Términos en inglés para direcciones reenviadas" . IETF . Archivado del original el 11-12-2008 . Recuperado el 07-11-2008 . [ reenvío es] un término vago (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 del dominio debe tener una dirección IP .
  3. ↑ 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 algunos de sus campos pueden ser guardados por el servidor receptor en las cabeceras 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 destinatarios con copia oculta ).
  4. ↑ Dave Crocker (julio de 2009). "Mediadores" . Arquitectura de correo de Internet . IETF . sec. 5. doi : 10.17487/RFC5598 . RFC 5598. Recuperado el 19 de marzo de 2013. Un mediador reenvía un mensaje mediante un proceso de reenvío. El mediador comparte algunas funcionalidades con el reenvío básico de MTA, pero tiene mayor flexibilidad tanto en el direccionamiento como en el contenido que la que ofrecen 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 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. 1 2 3 Considere la siguiente trayectoria hacia adelante:
    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 según la RFC 7208. En otras palabras, no se puede distinguir formalmente entre el simple reenvío de mensajes y el uso indebido de nombres de dominio.
  9. ↑ Véase la nota en la sección 6.2.7 Especificación explícita de la ruta de RFC 822
  10. ↑ El registro MX se introdujo con RFC 974. Consulte la sección histórica en Registro MX#Historial de la opción de reserva A.
  11. ↑ El reenvío de mensajes simple 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.
  12. ↑ Franck Martin; Eliot Lear; Tim Draegen; Elizabeth Zwicky; Kurt Andersen, eds. (septiembre de 2016). "Alias" . Problemas de interoperabilidad entre la autenticación, la notificación y la conformidad de mensajes basados ​​en dominio (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 corriente(versión 8.708 de 2006) La documentación de sendmail no menciona restricciones en el uso del -finterruptor y utiliza el verbo establecer en lugar de anular para describir su acción sobre los datos del remitente del sobre.
  14. ↑ Las fechas del libro en client-server-faqEl periodo de uso data de principios de la década de 1990. Si bien las llamadas a procedimientos remotos se originaron en la década de 1970, no se generalizaron hasta que las redes se hicieron bastante comunes.