Articulo de referencia

Cliente de correo electrónico

Interfaz de usuario del cliente de correo electrónico Mozilla Thunderbird en un sistema operativo Linux Un cliente de correo electrónico , lector de correo electrónico , agente ...

Interfaz de usuario del cliente de correo electrónico Mozilla Thunderbird en un sistema operativo Linux

Un cliente de correo electrónico , lector de correo electrónico , agente de usuario de mensajes ( MUA ) o agente de usuario de correo es un programa informático que se utiliza para acceder y gestionar el correo electrónico de un usuario .

Una aplicación web que proporciona funciones de gestión, redacción y recepción de mensajes puede funcionar como un cliente de correo web , y un componente de hardware o software informático cuya función principal o más visible sea la de funcionar como cliente de correo electrónico también puede utilizar este término.

Recuperación de mensajes de un buzón de correo

Como la mayoría de los programas cliente, un cliente de correo electrónico solo está activo cuando un usuario lo ejecuta. Lo habitual es que el usuario (el cliente) establezca un acuerdo con un servidor remoto de Agente de Transferencia de Correo (MTA) para la recepción y el almacenamiento de sus correos electrónicos. El MTA, mediante un agente de entrega de correo (MDA) adecuado, añade los mensajes al almacenamiento del cliente a medida que llegan. Este almacenamiento remoto se denomina buzón del usuario . La configuración predeterminada en muchos sistemas Unix es que el servidor de correo almacene los mensajes formateados en mbox , dentro del directorio personal del usuario . Por supuesto, los usuarios del sistema pueden iniciar sesión y ejecutar un cliente de correo en el mismo ordenador que aloja sus buzones; en cuyo caso, el servidor no es realmente remoto , salvo en un sentido genérico.

Los correos electrónicos se almacenan en el buzón del usuario en el servidor remoto hasta que el cliente de correo solicita su descarga al ordenador del usuario o accede a él en dicho servidor. El cliente de correo puede configurarse para conectarse a varios buzones simultáneamente y solicitar la descarga de correos automáticamente, por ejemplo, a intervalos preestablecidos, o bien el usuario puede iniciar la solicitud manualmente.

Se puede acceder al buzón de correo de un usuario de dos maneras específicas. El Protocolo de Oficina Postal (POP) permite al usuario descargar los mensajes uno a uno y solo los elimina del servidor una vez que se han guardado correctamente en el almacenamiento local. Es posible dejar mensajes en el servidor para que otro cliente pueda acceder a ellos. Sin embargo, no existe ninguna opción para marcar un mensaje específico como leído , respondido o reenviado , por lo que POP no resulta conveniente para usuarios que acceden al mismo correo desde diferentes equipos.

Como alternativa, el Protocolo de Acceso a Mensajes de Internet (IMAP) permite a los usuarios conservar los mensajes en el servidor, marcándolos según corresponda. IMAP proporciona carpetas y subcarpetas que pueden compartirse entre diferentes usuarios con distintos permisos de acceso. Normalmente, las carpetas Enviados , Borradores y Papelera se crean por defecto. IMAP incluye una extensión de inactividad para actualizaciones en tiempo real, que proporciona notificaciones más rápidas que el sondeo, cuando es posible mantener conexiones estables. Consulte también la sección de mensajes remotos a continuación.

El protocolo de aplicación JSON Meta (JMAP) se implementa utilizando API JSON sobre HTTP y se ha desarrollado como una alternativa a IMAP/SMTP.

Además, se puede acceder al almacenamiento del buzón directamente mediante programas que se ejecutan en el servidor o a través de discos compartidos . El acceso directo puede ser más eficiente, pero es menos portátil, ya que depende del formato del buzón; lo utilizan algunos clientes de correo electrónico, incluidas algunas aplicaciones de correo web .

Composición del mensaje

Los clientes de correo electrónico suelen incluir interfaces de usuario para visualizar y editar texto. Algunas aplicaciones permiten el uso de un editor externo al programa.

Los clientes de correo electrónico realizarán el formato según RFC 5322 para los encabezados y el cuerpo , y MIME para el contenido no textual y los archivos adjuntos. Los encabezados incluyen los campos de destino, Para , CC (abreviatura de Copia carbón ) y CCO ( Copia carbón oculta ), y los campos de origen De que es el autor o autores del mensaje, Remitente en caso de que haya más autores, y Responder-A en caso de que las respuestas deban dirigirse a un buzón diferente. Para ayudar mejor al usuario con los campos de destino, muchos clientes mantienen una o más libretas de direcciones y/o pueden conectarse a un servidor de directorio LDAP . Para los campos de origen, los clientes pueden admitir diferentes identidades. 

La configuración del cliente requiere el nombre real y la dirección de correo electrónico del usuario para la identidad de cada usuario, y posiblemente una lista de servidores LDAP.

Envío de mensajes a un servidor

Cuando un usuario desea crear y enviar un correo electrónico, el cliente de correo electrónico se encarga de la tarea. El cliente de correo electrónico suele configurarse automáticamente para conectarse al servidor de correo del usuario, que normalmente es un MSA o un MTA , dos variantes del protocolo SMTP . El cliente de correo electrónico que utiliza el protocolo SMTP crea una extensión de autenticación que el servidor de correo utiliza para autenticar al remitente. Este método facilita la modularidad y la informática móvil. El método anterior consistía en que el servidor de correo reconociera la dirección IP del cliente, por ejemplo, porque el cliente se encuentra en la misma máquina y utiliza la dirección interna 127.0.0.1, o porque la dirección IP del cliente está controlada por el mismo proveedor de servicios de Internet que proporciona tanto el acceso a Internet como los servicios de correo electrónico.

La configuración del cliente requiere el nombre o la dirección IP del servidor de correo saliente preferido , el número de puerto y el nombre de usuario y la contraseña para la autenticación, si corresponde. Los siguientes puertos se utilizan para el envío de correo electrónico:

- Puerto 465 : El puerto designado oficialmente para el envío de correo mediante TLS desde el inicio de la conexión (TLS implícito), según la RFC 8314. Dado que el cifrado se aplica desde el principio, se elimina el riesgo de ataques de degradación o ataques de intermediario (Man-in-the-Middle) que podrían anular el cifrado.

- Puerto 587 : Se utiliza habitualmente para el envío de correo electrónico y admite STARTTLS , lo que permite actualizar opcionalmente la conexión a TLS. Sin embargo, si un atacante intermediario (MITM) interfiere con el comando STARTTLS, la conexión puede permanecer sin cifrar, lo que la hace menos segura que el TLS implícito en el puerto 465.

El puerto 25, originalmente destinado al reenvío de mensajes entre MTA, no se utiliza para el envío de mensajes de clientes y, a menudo, los ISP lo bloquean para evitar el spam.

Cifrado

Sin cifrado, al igual que ocurre con las postales, la actividad del correo electrónico es claramente visible para cualquier intruso ocasional. El cifrado de correo electrónico permite proteger la privacidad al cifrar las sesiones de correo, el cuerpo del mensaje o ambos. Sin él, cualquier persona con acceso a la red y las herramientas adecuadas puede monitorizar el correo electrónico y obtener las contraseñas de inicio de sesión. Algunos ejemplos de situaciones preocupantes son la censura y la vigilancia gubernamentales , así como la vigilancia de otros usuarios de redes inalámbricas, como en un cibercafé .

Todos los protocolos de correo electrónico relevantes ofrecen la opción de cifrar toda la sesión para evitar que se intercepten el nombre de usuario y la contraseña . Se recomienda encarecidamente su uso para usuarios móviles y cuando no se confía en el proveedor de acceso a Internet . [ 1 ] Al enviar correo, los usuarios solo pueden controlar el cifrado en el primer salto desde el cliente hasta su servidor de correo saliente configurado . En cualquier salto posterior, los mensajes pueden transmitirse con o sin cifrado, dependiendo únicamente de la configuración general del servidor transmisor y de las capacidades del receptor.

Las sesiones de correo cifrado entregan los mensajes en su formato original, es decir, texto plano o cuerpo cifrado, tanto en el buzón local del usuario como en el servidor de destino. Este último servidor es operado por un proveedor de servicios de alojamiento de correo electrónico , posiblemente una entidad distinta del proveedor de acceso a Internet que se esté utilizando.

El cifrado de una sesión de recuperación de correo electrónico con, por ejemplo, SSL, puede proteger ambas partes (autenticación y transferencia de mensajes) de la sesión. [ 2 ] [ 3 ]

Alternativamente, si el usuario tiene acceso SSH a su servidor de correo, puede usar el reenvío de puertos SSH para crear un túnel cifrado a través del cual recuperar sus correos electrónicos. [ 4 ]

Cifrado del cuerpo del mensaje

Existen dos modelos principales para la gestión de claves criptográficas. S/MIME emplea un modelo basado en una autoridad de certificación (CA) de confianza que firma las claves públicas de los usuarios. OpenPGP utiliza un mecanismo de red de confianza algo más flexible que permite a los usuarios firmar las claves públicas de otros usuarios. OpenPGP también es más flexible en el formato de los mensajes, ya que sigue siendo compatible con el cifrado y la firma de mensajes sin cifrar, tal como funcionaban antes de la estandarización de MIME .

En ambos casos, solo se cifra el cuerpo del mensaje. Los campos de encabezado, incluidos el remitente, los destinatarios y, a menudo, el asunto, permanecen en texto plano.

Correo web

Además de los clientes de correo electrónico que se ejecutan en un ordenador de escritorio, existen aquellos alojados remotamente, ya sea como parte de una instalación remota de UNIX accesible mediante telnet (es decir, una cuenta de shell ) o alojados en la web . Ambos enfoques presentan varias ventajas: permiten enviar y recibir correo electrónico fuera de la red habitual del usuario mediante un navegador web o un cliente telnet, eliminando así la necesidad de instalar un cliente de correo electrónico específico en el dispositivo del usuario.

Algunos sitios web se dedican a proporcionar servicios de correo electrónico, y muchos proveedores de servicios de Internet ofrecen servicios de correo web como parte de su paquete de servicios de Internet. Las principales limitaciones del correo web son que las interacciones del usuario dependen del sistema operativo del sitio web y la imposibilidad general de descargar mensajes de correo electrónico y redactarlos o trabajar en ellos sin conexión, aunque existen paquetes de software que pueden integrar partes de la funcionalidad del correo web en el sistema operativo (por ejemplo, crear mensajes directamente desde aplicaciones de terceros a través de MAPI ).

Al igual que IMAP y MAPI, el correo web permite que los mensajes de correo electrónico permanezcan en el servidor de correo. Consulte la siguiente sección .

Mensajes remotos

POP3 ofrece la opción de dejar los mensajes en el servidor. Por el contrario, tanto IMAP como el correo web mantienen los mensajes en el servidor como método de funcionamiento, aunque los usuarios pueden crear copias locales si lo desean. Mantener los mensajes en el servidor tiene ventajas y desventajas. [ 5 ]

Ventajas

  • Se puede acceder a los mensajes desde distintos ordenadores o dispositivos móviles en diferentes ubicaciones, utilizando diferentes clientes.
  • El servidor suele proporcionar algún tipo de copia de seguridad.

Desventajas

  • Con un ancho de banda limitado, el acceso a mensajes largos puede ser prolongado, a menos que el cliente de correo electrónico almacene en caché una copia local.
  • Pueden existir problemas de privacidad, ya que los mensajes que permanecen en el servidor en todo momento tienen más probabilidades de ser accedidos casualmente por el personal de TI, a menos que se utilice el cifrado de extremo a extremo .

Protocolos

Los protocolos más comunes para recuperar correo son POP3 e IMAP4 . El envío de correo generalmente se realiza mediante el protocolo SMTP .

Otro estándar importante compatible con la mayoría de los clientes de correo electrónico es MIME , que se utiliza para enviar archivos binarios adjuntos . Los archivos adjuntos no forman parte del correo electrónico propiamente dicho, sino que se envían junto con él.

La mayoría de los clientes de correo electrónico utilizan un campo de encabezado User-Agent [ 6 ] para identificar el software utilizado para enviar el mensaje. Este campo de encabezado está definido para Netnews, pero no para el correo electrónico y, como tal, no es estándar [ 7 ] en los encabezados de correo electrónico.

El RFC 6409 , Envío de mensajes para correo electrónico , detalla la función del agente de envío de correo electrónico . 

El RFC 5068 , Operaciones de envío de correo electrónico: Requisitos de acceso y rendición de cuentas , ofrece un análisis de los conceptos de MTA, MSA, MDA y MUA. Menciona que " los proveedores de acceso NO DEBEN bloquear el acceso de los usuarios a Internet externo mediante el puerto de ENVÍO 587 " y que " los MUA DEBEN utilizar el puerto de ENVÍO para el envío de mensajes " . 

RFC 5965 , Un formato extensible para informes de comentarios por correo electrónico , proporciona "un formato extensible y un tipo MIME que los operadores de correo pueden utilizar para informar a otras partes sobre los comentarios recibidos por correo electrónico". 

Números de puerto

Los servidores y clientes de correo electrónico utilizan por convención los números de puerto TCP que aparecen en la siguiente tabla. Para MSA, IMAP y POP3, la tabla también muestra las etiquetas que un cliente puede usar para consultar los registros SRV y descubrir tanto el nombre de host como el número de puerto del servicio correspondiente. [ 8 ]

Si bien el correo web respeta la configuración HTTP anterior de tener puertos separados para sesiones cifradas y de texto plano, los protocolos de correo utilizan la técnica STARTTLS , lo que permite que el cifrado comience en una conexión TCP ya establecida. Aunque el RFC 2595 desaconsejaba el uso de los puertos 995 y 993, establecidos previamente, el RFC 8314 promueve el uso de TLS implícito cuando esté disponible.  

Protocolos de cliente patentados

Los sistemas de correo de Microsoft utilizan la interfaz de programación de aplicaciones de mensajería (MAPI), de propiedad exclusiva , en aplicaciones cliente como Microsoft Outlook para acceder a los servidores de correo electrónico de Microsoft Exchange .

Véase también

Referencias

  1. C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch (noviembre de 2007). "Tecnologías de autenticación/autorización para el envío de mensajes" . Operaciones de envío de correo electrónico: requisitos de acceso y responsabilidad . IETF . sec. 5. doi : 10.17487/RFC5068 . BCP 134. RFC 5068. Recuperado el 24 de agosto de 2011. Este documento no proporciona recomendaciones sobre implementaciones de seguridad específicas. Simplemente advierte que se DEBE evitar transmitir credenciales de usuario en texto plano a través de redes inseguras en todos los escenarios, ya que esto podría permitir a los atacantes escuchar este tráfico y robar datos de la cuenta. En estos casos, se sugiere encarecidamente que se DEBE utilizar una tecnología de seguridad apropiada. 
  2. Sill 2003 , p. 353: "Al igual que SMTP, POP3 no está cifrado. Sin embargo, a diferencia de SMTP, requiere autenticación: los usuarios deben identificarse y demostrar que son quienes dicen ser. Desafortunadamente, la autenticación generalmente consiste en presentar un nombre de usuario y una contraseña conocidos solo por el usuario y el servidor POP3. Debido a que el diálogo POP3 no está cifrado, un intruso puede obtener el nombre de usuario y la contraseña de un usuario y reutilizarlos para acceder a su buzón de correo. Por lo tanto, POP3 sin cifrar expone el contenido de los mensajes de correo que el usuario recupera, así como su nombre de usuario y contraseña, que luego pueden ser reutilizados por otra persona.Envolver el diálogo POP3 con seguridad de capa de transporte, como SSL, resuelve ambos problemas. Debido a que las sesiones POP3 envueltas en SSL están cifradas de principio a fin, ningún mensaje, nombre de usuario o contraseña se expone en texto plano.El comando POP3 opcional,APOP, reemplaza la autenticación estándarUSER/PASScon un mecanismo de autenticación de desafío-respuesta. Esto resuelve el problema de la divulgación de contraseñas reutilizables, pero no impide que los intrusos lean Los mensajes de correo electrónico de los usuarios a medida que se van recuperando."
  3. Procedimiento actualizado de verificación de identidad del servidor de seguridad de la capa de transporte (TLS) para protocolos relacionados con el correo electrónico . IETF . doi : 10.17487/RFC7817 . RFC 7817 .
  4. Flickenger, Rob (2003). Trucos para servidores Linux: 100 consejos y herramientas de nivel profesional . O'Reilly Media . pág . 146. ISBN  978-0596004613Además de proporcionar acceso remoto a la consola y ejecución de comandos, OpenSSH puede reenviar puertos TCP arbitrarios al otro extremo de la conexión. Esto puede ser muy útil para proteger el correo electrónico, la web o cualquier otro tráfico que necesite mantener privado (al menos, hasta el otro extremo del túnel). ssh realiza el reenvío local enlazándose a un puerto local, realizando el cifrado, enviando los datos cifrados al extremo remoto de la conexión ssh , luego descifrándolos y enviándolos al host y puerto remotos que especifique. Inicie un túnel ssh con el modificador -L (abreviatura de Local): Naturalmente, sustituya "user" por su nombre de usuario y "mailhost" por el nombre o la dirección IP de su servidor de correo. Tenga en cuenta que deberá ser root en el portátil para este ejemplo, ya que se enlazará a un puerto privilegiado (110, el puerto POP). También debe deshabilitar cualquier demonio POP que se ejecute localmente (consulte /etc/inetd.conf ) o interferirá. Para cifrar todo tu tráfico POP, configura tu cliente de correo para que se conecte al puerto 110 de localhost. Se comunicará con el servidor de correo como si estuviera conectado directamente, con la diferencia de que toda la conversación estará cifrada.root@laptop:~# ssh -f -N -L110:mailhost:110 -l usermailhost
  5. "¿Es IMAP adecuado para mí?" . Servicios de TI . Universidad de Stanford . 4 de marzo de 2010. Archivado del original el 30 de abril de 2010 . Consultado el 14 de abril de 2013 .
  6. " User-Agent" . Formato de artículo de Netnews . IETF . Noviembre de 2009. Sec. 3.2.13. doi : 10.17487/RFC5536 . RFC 5536. Parte de esta información se ha enviado previamente en campos de encabezado no estandarizados como X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent y otros. 
  7. J. Palme (febrero de 1997). "Uso de encabezados de puerta de enlace" . Encabezados comunes de mensajes de Internet . IETF . sec. 2. doi : 10.17487/RFC2076 . RFC 2076. Recuperado el 11 de mayo de 2015. Los encabezados definidos solo en RFC 1036 para su uso en Usenet News a veces aparecen en mensajes de correo, ya sea porque los mensajes han sido enviados desde Usenet News al correo electrónico, o porque los mensajes fueron escritos en clientes combinados que admiten tanto correo electrónico como Usenet News en el mismo cliente. Estos encabezados no están estandarizados para su uso en el correo electrónico de Internet y los agentes de correo electrónico deben manejarlos con precaución. 
  8. Cyrus Daboo (marzo de 2011). Uso de registros SRV para localizar servicios de envío/acceso de correo electrónico . IETF . doi : 10.17487/RFC6186 . RFC 6186. Consultado el 17 de abril de 2013 .
  9. Keith Moore; Chris Newman (enero de 2018). El texto plano se considera obsoleto: uso de la seguridad de la capa de transporte (TLS) para el envío y acceso por correo electrónico . IETF . doi : 10.17487/RFC8314 . RFC 8314. Consultado el 12 de febrero de 2018 .

Bibliografía

  • Sill, Dave (2003). El manual de qmail . Apress . ISBN 9781430211341.
  • Partridge, Craig (abril-junio de 2008). "El desarrollo técnico del correo electrónico en Internet" (PDF) . IEEE Annals of the History of Computing . 30 (2): 3–29 . Bibcode : 2008IAHC...30b...3P . doi : 10.1109/mahc.2008.32 . ISSN 1934-1547 . S2CID 206442868. Archivado del original (PDF) el 12 de mayo de 2011.