Cliente de correo electrónico

Programa informático utilizado para acceder y gestionar el correo electrónico de un usuario.

Un cliente de correo electrónico , un lector de correo electrónico o, más formalmente, un agente de usuario de mensajes (MUA) o un agente de usuario de correo es un programa informático utilizado para acceder y administrar el correo electrónico de un usuario .

Una aplicación web que proporciona funciones de gestión, composición y recepción de mensajes puede actuar como un cliente de correo electrónico web , y un elemento de hardware o software de computadora cuya función principal o más visible es funcionar como un cliente de correo electrónico también puede utilizar el término.

Recuperar mensajes de un buzón de correo

Al igual que la mayoría de los programas cliente, un cliente de correo electrónico solo está activo cuando un usuario lo ejecuta. El acuerdo habitual es que un usuario de correo electrónico (el cliente) haga un acuerdo con un servidor de Agente de transferencia de correo (MTA) remoto para la recepción y el almacenamiento de los correos electrónicos del cliente. El MTA, utilizando un agente de entrega de correo (MDA) adecuado, agrega mensajes de correo electrónico al almacenamiento de un cliente a medida que llegan. El almacenamiento de correo remoto se conoce como el 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 de inicio del usuario . Por supuesto, los usuarios del sistema pueden iniciar sesión y ejecutar un cliente de correo en la misma computadora que aloja sus buzones de correo; en cuyo caso, el servidor no es realmente remoto , salvo en un sentido genérico.

Los mensajes de correo electrónico se almacenan en el buzón del usuario en el servidor remoto hasta que el cliente de correo electrónico del usuario solicita que se descarguen en el equipo del usuario o puede acceder de otro modo al buzón del usuario en el servidor remoto. El cliente de correo electrónico se puede configurar para que se conecte a varios buzones de correo al mismo tiempo y solicite la descarga de mensajes de correo electrónico de forma automática, por ejemplo a intervalos preestablecidos, o el usuario puede iniciar la solicitud de forma manual.

Se puede acceder al buzón de un usuario de dos formas específicas. El Protocolo de Oficina Postal (POP) permite al usuario descargar mensajes de uno en uno y solo los elimina del servidor después de que se hayan guardado correctamente en el almacenamiento local. Es posible dejar mensajes en el servidor para permitir que otro cliente acceda a ellos. Sin embargo, no existe ninguna disposición para marcar un mensaje específico como visto , respondido o reenviado , por lo que el protocolo POP no es conveniente para los usuarios que acceden al mismo correo desde diferentes máquinas.

Como alternativa, el Protocolo de acceso a mensajes de Internet (IMAP) permite a los usuarios mantener los mensajes en el servidor y marcarlos como apropiados. IMAP proporciona carpetas y subcarpetas que se pueden compartir entre diferentes usuarios con diferentes derechos de acceso. Normalmente, las carpetas Enviados , Borradores y Papelera se crean de forma predeterminada. IMAP cuenta con una extensión inactiva para actualizaciones en tiempo real, lo que proporciona una notificación más rápida que el sondeo, donde es posible establecer conexiones duraderas. Consulte también la sección de mensajes remotos a continuación.

El protocolo de aplicación meta JSON (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 mediante 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.

Redacción del mensaje

Los clientes de correo electrónico suelen contener 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 de acuerdo con RFC 5322 para encabezados y cuerpo , y MIME para contenido no textual y archivos adjuntos. Los encabezados incluyen los campos de destino, Para , Cc (abreviatura de Copia de carbón ) y Cco ( Copia de carbón oculta ), y los campos de origen De , que es el autor o los 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 de correo 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 del usuario y la dirección de correo electrónico 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 encargará de la tarea. El cliente de correo electrónico suele configurarse automáticamente para conectarse al servidor de correo del usuario, que suele ser 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 computación nómada. El método más antiguo consistía en que el servidor de correo reconociera la dirección IP del cliente, por ejemplo, porque el cliente está 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 acceso a Internet como servicios de correo.

La configuración del cliente requiere el nombre o la dirección IP del servidor de correo saliente preferido , el número de puerto (25 para MTA, 587 para MSA) y el nombre de usuario y la contraseña para la autenticación, si corresponde. Existe un puerto no estándar, el 465, para sesiones SMTP cifradas con SSL , que muchos clientes y servidores admiten por compatibilidad con versiones anteriores.

Encriptación

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

Todos los protocolos de correo electrónico relevantes tienen una opción para cifrar toda la sesión, para evitar que el nombre y la contraseña de un usuario sean interceptados . Se recomiendan encarecidamente para usuarios nómadas y siempre que el proveedor de acceso a Internet no sea de confianza. ^{[1] Al enviar correo, los usuarios solo pueden controlar el cifrado en el primer salto desde un cliente a 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 de transmisión y las capacidades del servidor receptor.

Las sesiones de correo cifradas entregan los mensajes en su formato original, es decir, texto simple o cuerpo cifrado, en el buzón local del usuario y en el servidor de destino. Este último servidor es operado por un proveedor de servicios de alojamiento de correo electrónico , posiblemente una entidad diferente del proveedor de acceso a Internet en cuestión.

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 puerto 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 gestionar 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 emplea un mecanismo de red de confianza algo más flexible que permite a los usuarios firmar las claves públicas de los demás. OpenPGP también es más flexible en el formato de los mensajes, ya que sigue admitiendo el cifrado y la firma de mensajes simples 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 sin formato.

Correo web

Además de los clientes de correo electrónico que se ejecutan en una computadora de escritorio, existen aquellos que se alojan de forma remota, ya sea como parte de una instalación remota de UNIX accesible por telnet (es decir, una cuenta shell ) o alojados en la Web . Ambos enfoques tienen varias ventajas: comparten la capacidad de enviar y recibir correo electrónico fuera de la base normal del usuario mediante un navegador web o un cliente telnet, eliminando así la necesidad de instalar un cliente de correo electrónico dedicado 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 de los usuarios están sujetas al sistema operativo del sitio web y la imposibilidad general de descargar mensajes de correo electrónico y redactar o trabajar en los mensajes 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 tiene una opción para dejar 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 hacer copias locales cuando lo deseen. Mantener los mensajes en el servidor tiene ventajas y desventajas. ^[5]

Ventajas

Se puede acceder a los mensajes desde varias computadoras o dispositivos móviles en diferentes ubicaciones, utilizando diferentes clientes.
Normalmente el servidor proporciona algún tipo de copia de seguridad.

Desventajas

Con un ancho de banda limitado, el acceso a mensajes largos puede llevar mucho tiempo, a menos que el cliente de correo electrónico almacene en caché una copia local.
Puede haber preocupaciones sobre la privacidad, ya que los mensajes que permanecen en el servidor en todo momento tienen más posibilidades de ser accedidos casualmente por el personal de TI, a menos que se utilice cifrado de extremo a extremo .

Protocolos

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

Otro estándar importante que admiten la mayoría de los clientes de correo electrónico es MIME , que se utiliza para enviar archivos binarios adjuntos a los correos electrónicos . Los archivos adjuntos son archivos que no forman parte del correo electrónico propiamente dicho, pero 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.

RFC 6409, Envío de mensajes por correo , detalla la función del agente de envío de correo .

RFC 5068, Operaciones de envío de correo electrónico: requisitos de acceso y responsabilidad , ofrece un estudio de los conceptos de MTA, MSA, MDA y MUA. Menciona que " los proveedores de acceso NO DEBEN bloquear a los usuarios para que no accedan 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 usar para informar comentarios sobre el correo electrónico recibido a otras partes".

Números de puerto

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

Protocolo	Usar	Texto simple o sesiones cifradas	Sesiones de texto simple únicamente	Cifrar únicamente sesiones
POP3	correo entrante	110 _pop3._tcp		995 _pop3s._tcp
IMAP4	correo entrante	143 _imap._tcp		993 _imaps._tcp
SMTP	Correspondencia saliente	25		587
MSA	Correspondencia saliente	587 _envío._tcp		465 ^[9] _envíos._tcp
HTTP	correo web		80	443

Mientras que el correo web sigue la disposición HTTP anterior de tener puertos separados para las sesiones cifradas y de texto sin formato, los protocolos de correo utilizan la técnica STARTTLS , lo que permite que el cifrado comience en una conexión TCP ya establecida. Mientras que el RFC 2595 solía desalentar el uso de los puertos 995 y 993, establecidos anteriormente, el RFC 8314 promueve el uso de TLS implícito cuando esté disponible.

Protocolos de cliente propietarios

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

Véase también

Referencias

^ C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch (noviembre de 2007). "Tecnologías de autenticación/autorización de 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 . Consultado el 24 de agosto de 2011 . Este documento no proporciona recomendaciones sobre implementaciones de seguridad específicas. Simplemente proporciona una advertencia de que la transmisión de credenciales de usuario en texto claro a través de redes inseguras DEBE evitarse en todos los escenarios, ya que esto podría permitir a los atacantes escuchar este tráfico y robar datos de cuentas. En estos casos, se recomienda encarecidamente que se DEBE utilizar una tecnología de seguridad adecuada.
^ Sill 2003, pág. 353: "Al igual que SMTP, POP3 no está cifrado. Sin embargo, a diferencia de SMTP, necesita autenticación: los usuarios tienen que identificarse y demostrar que son quienes dicen ser. Desafortunadamente, la autenticación generalmente consiste en presentar un nombre de usuario y una contraseña que sólo conocen el usuario y el servidor POP3. Debido a que el diálogo POP3 no está cifrado, un espía puede obtener el nombre de usuario y la contraseña de un usuario y reutilizarlos para acceder al buzón de correo del usuario. Por lo tanto, POP3 simple expone el contenido de los mensajes de correo que recupera el usuario y expone 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 con SSL están cifradas de principio a fin, no se exponen mensajes, nombres de usuario ni contraseñas en texto sin formato.
El comando POP3 opcional, APOP, reemplaza la USER/PASSautenticación estándar con un mecanismo de autenticación de desafío-respuesta. Esto resuelve el problema de la divulgación de contraseñas reutilizables, pero no hace nada para evitar que se revelen las contraseñas reutilizables. los espías pueden leer los mensajes de correo de los usuarios a medida que son recuperados".
^ 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. doi : 10.17487/RFC7817 . RFC 7817.
^ Flickenger, Rob (2003). Trucos para servidores Linux: 100 consejos y herramientas de nivel industrial . O'Reilly Media . pág. 146. ISBN. 978-0596004613Además de proporcionar acceso remoto a la shell y ejecución de comandos, OpenSSH puede reenviar puertos TCP arbitrarios al otro extremo de su 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 logra el reenvío local al vincularse a un puerto local, realizar el cifrado, enviar los datos cifrados al extremo remoto de la conexión ssh , luego descifrarlos y enviarlos al host remoto y puerto que especifique. Inicie un túnel ssh con el interruptor -L (abreviatura de Local): Naturalmente, sustituya user con su nombre de usuario y mailhost con el nombre o la dirección IP de su servidor de correo. Tenga en cuenta que deberá ser root en la computadora portátil para este ejemplo, ya que se vinculará a un puerto privilegiado (110, el puerto POP). También debe deshabilitar cualquier demonio POP que se ejecute localmente (busque en /etc/inetd.conf ) o se interpondrá en el camino. Ahora, para cifrar todo el tráfico POP, configure su cliente de correo para que se conecte al puerto local 110. Se comunicará con mailhost como si estuviera conectado directamente, excepto que toda la conversación estará cifrada.

root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost
^ "¿IMAP es adecuado para mí?". Servicios de TI . Universidad de Stanford . 4 de marzo de 2010. Consultado el 14 de abril de 2013 .
^ "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 anteriormente en campos de encabezado no estandarizados, como X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent y otros.
^ J. Palme (febrero de 1997). "Uso de encabezados de pasarela". Encabezados de mensajes comunes de Internet. sec. 2. doi : 10.17487/RFC2076 . RFC 2076 . Consultado el 11 de mayo de 2015 . Los encabezados definidos únicamente en RFC 1036 para su uso en Usenet News aparecen a veces en los mensajes de correo, ya sea porque los mensajes se han enviado desde Usenet News al correo electrónico o porque los mensajes se escribieron en clientes combinados que admiten tanto el 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.
^ Cyrus Daboo (marzo de 2011). Uso de registros SRV para localizar servicios de acceso/envío de correo electrónico. IETF . doi : 10.17487/RFC6186 . RFC 6186 . Consultado el 17 de abril de 2013 .
^ Keith Moore; Chris Newman (enero de 2018). Texto claro considerado obsoleto: uso de seguridad de la capa de transporte (TLS) para el envío y acceso a correos electrónicos. IETF . doi : 10.17487/RFC8314 . RFC 8314 . Consultado el 12 de febrero de 2018 .

Bibliografía

Sill, Dave (2003). 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. doi :10.1109/mahc.2008.32. ISSN 1934-1547. S2CID 206442868. Archivado desde el original (PDF) el 12 de mayo de 2011.

[1] C. Hutzler; D. Crocker; P. Resnick; E. Allman; T. Finch (noviembre de 2007). "Tecnologías de autenticación/autorización de 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 . Consultado el 24 de agosto de 2011 . Este documento no proporciona recomendaciones sobre implementaciones de seguridad específicas. Simplemente proporciona una advertencia de que la transmisión de credenciales de usuario en texto claro a través de redes inseguras DEBE evitarse en todos los escenarios, ya que esto podría permitir a los atacantes escuchar este tráfico y robar datos de cuentas. En estos casos, se recomienda encarecidamente que se DEBE utilizar una tecnología de seguridad adecuada.

[sill-security-2] Sill 2003, pág. 353: "Al igual que SMTP, POP3 no está cifrado. Sin embargo, a diferencia de SMTP, necesita autenticación: los usuarios tienen que identificarse y demostrar que son quienes dicen ser. Desafortunadamente, la autenticación generalmente consiste en presentar un nombre de usuario y una contraseña que sólo conocen el usuario y el servidor POP3. Debido a que el diálogo POP3 no está cifrado, un espía puede obtener el nombre de usuario y la contraseña de un usuario y reutilizarlos para acceder al buzón de correo del usuario. Por lo tanto, POP3 simple expone el contenido de los mensajes de correo que recupera el usuario y expone 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 con SSL están cifradas de principio a fin, no se exponen mensajes, nombres de usuario ni contraseñas en texto sin formato.
El comando POP3 opcional, APOP, reemplaza la USER/PASSautenticación estándar con un mecanismo de autenticación de desafío-respuesta. Esto resuelve el problema de la divulgación de contraseñas reutilizables, pero no hace nada para evitar que se revelen las contraseñas reutilizables. los espías pueden leer los mensajes de correo de los usuarios a medida que son recuperados".

[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. doi : 10.17487/RFC7817 . RFC 7817.

[4] Flickenger, Rob (2003). Trucos para servidores Linux: 100 consejos y herramientas de nivel industrial . O'Reilly Media . pág. 146. ISBN. 978-0596004613Además de proporcionar acceso remoto a la shell y ejecución de comandos, OpenSSH puede reenviar puertos TCP arbitrarios al otro extremo de su 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 logra el reenvío local al vincularse a un puerto local, realizar el cifrado, enviar los datos cifrados al extremo remoto de la conexión ssh , luego descifrarlos y enviarlos al host remoto y puerto que especifique. Inicie un túnel ssh con el interruptor -L (abreviatura de Local): Naturalmente, sustituya user con su nombre de usuario y mailhost con el nombre o la dirección IP de su servidor de correo. Tenga en cuenta que deberá ser root en la computadora portátil para este ejemplo, ya que se vinculará a un puerto privilegiado (110, el puerto POP). También debe deshabilitar cualquier demonio POP que se ejecute localmente (busque en /etc/inetd.conf ) o se interpondrá en el camino. Ahora, para cifrar todo el tráfico POP, configure su cliente de correo para que se conecte al puerto local 110. Se comunicará con mailhost como si estuviera conectado directamente, excepto que toda la conversación estará cifrada.

root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost

[5] "¿IMAP es adecuado para mí?". Servicios de TI . Universidad de Stanford . 4 de marzo 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 anteriormente 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 pasarela". Encabezados de mensajes comunes de Internet. sec. 2. doi : 10.17487/RFC2076 . RFC 2076 . Consultado el 11 de mayo de 2015 . Los encabezados definidos únicamente en RFC 1036 para su uso en Usenet News aparecen a veces en los mensajes de correo, ya sea porque los mensajes se han enviado desde Usenet News al correo electrónico o porque los mensajes se escribieron en clientes combinados que admiten tanto el 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 acceso/envío 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). Texto claro considerado obsoleto: uso de seguridad de la capa de transporte (TLS) para el envío y acceso a correos electrónicos. IETF . doi : 10.17487/RFC8314 . RFC 8314 . Consultado el 12 de febrero de 2018 .