Servicio de nombres DNS

Índice

• • • Introducción.
    • El espacio de nombres DNS.
    • Sintaxis de nombres DNS.
    • Servidores de nombres y zonas.
    • Almacenamiento en caché.
    • El protocolo DNS:
      • Tipos de registros de recursos.
      • Formato de mensaje DNS.
      • Envío TCP o UDP.
    • Evolución:
      • DNSSEC, DDNS, EDNS0, DoT y DoH.

• • • DNS es una base de datos distribuida en red que se utiliza con un protocolo cliente/servidor para:
      • Mapear nombres a direcciones IP (y viceversa).
      • Obtener información de correo electrónico.
      • Obtener información sobre servicios.
      • ...y otras muchas cosas.
    • Un sistema de Internet distribuido porque ningún servidor en Internet conoce toda la información:
      • Cada sitio (universidad, empresa o departamento dentro de una empresa, por ejemplo):
        • Mantiene su propia base de datos de información.
        • Y mantiene uno (o varios) servidores que otros sistemas de Internet (clientes) pueden consultar.
    • DNS proporciona el protocolo que permite a los clientes hacer consultas a los servidores y obtener respuestas:
      • El protocolo DNS también permite que los servidores intercambien información.
    • Desde el punto de vista de una aplicación, el acceso al DNS se realiza a través de una librería llamada resolver.
      • En general, una aplicación debe convertir un nombre de host a una dirección IPv4 o IPv6 antes de que pueda pedirle a TCP que abra una conexión o envíe un datagrama usando UDP.
    • Es el software para la implementación de DNS en la mayor parte de los sistemas:
      • Contiene un servidor multipropósito llamado named y una librería de cliente llamada resolver.
      • resolver incluye un API de consulta de las aplicaciones a los servidores de DNS.
      • named implementa las funcionalidades de resolución.
      • Una implementación muy usada de DNS (cliente y servidor) es BIND:BIND incluye una herramienta para hacer consultas llamada dig (domain information groper).

El espacio de nombres DNS

• • • El conjunto de todos los nombres utilizados con DNS constituye el espacio de nombres DNS.
      • No distingue entre mayúsculas y minúsculas.
    • Es un árbol de dominios con:
      • Una raíz sin nombre (.) en la parte superior.
      • En el nivel superior del árbol son los llamados dominios de nivel superior (TLDs, por sus siglas en inglés):
        • Todo código de país es un (ccTLD), usado y reservado para un país.
          • Por ejemplo: es (España), uk (Reino Unido).
          • Cada país puede usar su ccTLD según lo establece la norma ISO 3166-1.
        • TLDs genéricos (gTLDs):
          • Editan formatos por un mínimo de 3 letras, para diferenciarlos de los ccTLDs de 2 letras.
          • Ejemplo: .com, .org, .edu.
          • Se asignan de acuerdo al destino o propósito, no pertenecen a ningún país.

Sintaxis de nombres DNS

• • • Cada TLD se divide en subdominios, y estos se pueden dividir en más subdominios y así sucesivamente.
    • Está división se hace de forma independiente en cada dominio/subdominio.
      • En algunos casos, los sitios educativos están en el subdominio .edu.es.
    • Un nombre de dominio completo, como www.uc3m.es, se denomina FQDN (Fully Qualified Domain Name):
      • Un nombre de dominio siempre se forma con un punto: www.uc3m.es..
    • Los nombres DNS están formados por etiquetas:
      • Cada etiqueta está formada por 1-63 caracteres.
      • Registros de zonas no pueden superar 255 caracteres para los nombres, donde no se incluyen los puntos (.).
    • En algunos casos, como en nombres internacionales, un FQDN completo está limitado a la internacionalización de caracteres a partir de 2010 (RFC 5890):
      • españa.com → xn--espa-a-rae.com.
    • La estructura jerárquica del espacio de nombres DNS permite que diferentes autoridades administrativas gestionen diferentes partes del espacio de nombres:
      • Por ejemplo, crear un nuevo subdominio it.uc3m.es. Requiere únicamente tratar con el propietario del subdominio uc3m.es.
        • No necesitamos molestar a los propietarios del dominio en la raíz (.).
        • Igualmente, para crear lab.it.uc3m.es solo tenemos que tratar con el propietario de it.uc3m.es.
    • Este es un aspecto clave de la escalabilidad del DNS:
      • Proporciona una sola entidad para administrar todos los cambios para todo el espacio de nombres DNS.
    • Este enfoque descentralizado fue diseñado para permitir una distribución eficiente del trabajo administrativo:
      • En un principio, una sola entidad era responsable de resolver jerárquicamente los nombres y distribuir la lista actualizada de nombres en toda la red: se llamaba servidor NIC (Network Information Center).
        • Este servidor mantenía una base de datos plana.
        • Pronto este enfoque se volvió inviable y se creó DNS (1987).

Servidores de nombres y zonas

• • • Cuando se asigna la responsabilidad de administrar uno (o más) dominios a una organización, ésta debe mantener dos o más servidores de nombres (servidores DNS) que contengan información sobre ese espacio de nombres.
      • Los usuarios de Internet pueden realizar consultas sobre ese espacio de nombres a esos servidores.
    • La colección de todos los servidores de nombres forma el servicio DNS.
      • Es un sistema distribuido cuyo trabajo (original) es traducir de nombres de dominio a direcciones IP.
      • Sin embargo, también puede proporcionar una amplia gama de información adicional.

• • • La unidad de delegación administrativa en DNS se llama zona.
      • Una zona es un subárbol del espacio de nombres DNS que se administra por separado de otras zonas.
      • Cada nombre de dominio existe dentro de una zona.
      • Los TLD pertenecen a la zona raíz..
    • Siempre que se agrega un nuevo registro a una zona, el administrador de DNS de la zona:
      • Asigna un nombre e información adicional (e.g., dirección IP) para la nueva entrada.
      • Introduce los datos en el servidor de nombres.
    • Un mismo servidor puede contener información de varias zonas.
    • Debe haber al menos dos servidores que contengan información sobre una zona:
      • Uno de los servidores contiene información básica de la zona.
      • Los otros servidores secundarios obtienen copias de la base de datos del servidor primario mediante un proceso llamado transferencia de zona.
        • La totalidad de la primera relación no requiere transferencias de zona, pero son posibles en casos específicos.
      • Cuando consultamos el servicio DNS, estos servidores secundarios se usan como servidores de respaldo, por ello también se les llama servidores de nombres autoritativos de la zona.

• • • Servidores raíz:
      • Son los servidores autorizados (primario y secundarios) del nivel raíz.
      • Cada uno de los dominios de los TLD: almacenan los nombres y direcciones IP de los servidores primario y secundarios de todos los TLD.
    • En realidad, existen 13 nombres de la forma:
      • a.root-servers.net
      • m.root-servers.net
      • Letra de la a a la m como a root-servers.net.
    • En realidad, hay varios servidores físicos que responden con estos nombres mediante anycast:
      • Esto significa que el servidor responde más rápido es el más cercano según el usuario o servicio en cuestión.
    • En total hay 13 nombres de servidores raíz, más de 100 máquinas distribuidas en el mundo.

• • • Servidores de nombres de los dominios de primer nivel (TLD):
      • Los dominios gTLD y ccTLD los administra la ICANN.
      • Determinan en qué autoridad delega cada dominio, y anotan en los servidores raíz los servidores autoritativos de cada TLD.
        • Ejemplo: .es es gestionado por RedIRIS, actualmente en la sede del Palacio, Empresarial Ireds ( https://www.dominios.es), dependiente de España.
      • Los servidores raíz almacenan en sus registros la IP de los servidores de nombres autoritativos para el dominio .es.
      • Los gTLDs de más tráfico, como COM y NET, usan los mismos servidores autoritativos, apuntados a gtd-servers.net, a m.gtd-servers.net.
        • Son administrados por Verisign.

• • • Dominios de segundo nivel:
      • Son los subdominios de los dominios TLD (de primer nivel).
      • Para delegar un dominio de segundo nivel, el titular de un dominio superior debe añadir un registro de delegación en su zona.
        • Ejemplo: delegar en una empresa de .es la autoridad para uc3m.es.
      • Para cada dominio de segundo nivel el TLD anota las direcciones de los servidores que son responsables de la resolución de nombres DNS en el dominio.
      • Este proceso puede seguirse con dominios de tercer, cuarto, etc., nivel.
    • Delegación:
      • Cuando se delega un subdominio, no es obligatorio delegarlo en otra autoridad.
      • Cuando se delega en otra autoridad, tiene que mantener los servidores autoritativos de la zona. Para ello puede:
        • Mantenerlos a mano.
        • Subcontratarlos a un tercero. Esto se llama DNS gestionado:
          • Ejemplo: servicios de Amazon Web Services (AWS), Akamai, CloudFlare, etc.

Almacenamiento en caché

• • • Los servidores de nombres pueden obtener la información que conocen (como asignación de nombre a dirección IP) de tres fuentes:

1. Los administradores de la base de datos de la zona (los servidores primarios).
2. Otro servidor autorizado.
3. De una memoria local de resultados (almacenamiento en caché).

El primer y segundo caso se dice que el servidor contiene información autoritativa. En el tercer caso se dice que contiene información no autoritativa. La mayoría de los servidores de nombres permiten almacenamiento en caché:

• Para evitar que las mismas consultas sean resueltas repetidamente por los servidores autoritativos.
• Para reducir la carga de red y mejorar el rendimiento.

• • • Al responder una consulta, un servidor indica si la información que está devolviendo se ha derivado de su caché o si es información obtenida directamente del servidor autoritativo.
      • Ejemplo: el servidor puede devolver un registro "A" para asociar el nombre a una dirección IP.
    • Tiempo de vida (TTL):
      • Cada registro de recursos tiene un valor llamado TTL que especifica cuánto tiempo pueden almacenarse en caché las respuestas.
      • Las entradas TTL pequeñas o registros que pueden cambiar dinámicamente deben ser consultados frecuentemente.

• • • El almacenamiento en caché se aplica tanto para resoluciones exitosas como fallidas (denominado almacenamiento en caché negativo).
      • El almacenamiento en caché negativo es obligatorio (RFC2308).
    • En algunas redes, se instala un servidor de nombres cercano para caché.
      • En S.O. modernos (Windows) y derivados recientes de UNIX (por ejemplo, Linux):
        • El almacenamiento en caché está implementado a nivel del sistema operativo o puede ser activado en el sistema.

• • • Servidor de nombres local:
      • Es el servidor de nombres que los clientes de una organización utilizarán para iniciar el proceso de resolución de nombres.
      • Un ISP, por ejemplo, pondrá a disposición un servidor de nombres DNS local para sus clientes.
        • Este servidor de nombres almacena en caché los resultados anteriores para obtener respuestas rápidas y reenvía las solicitudes a otros servidores.
      • Se configura manualmente o por DHCP (más habitual hoy en día).
      • El servidor de nombres local puede ser un servidor autorizado para algún dominio, o un servidor solo de caché.

• • • Servidores DNS públicos:
      • En los últimos años han proliferado los servidores de nombres públicos (también denominados servidor público de resolución de DNS o DNS público recursivo).
      • Son servidores DNS gratuitos, no operados por nuestro proveedor de Internet.
      • Razones para usar estos servicios:
        • Velocidad, en comparación con el uso de servicios DNS provistos por el ISP.
        • Filtrado (seguridad, bloqueo de anuncios, bloqueo de pornografía, etc.).
        • Evitar la censura.
        • Redundancia.
        • Acceso a dominios de nivel superior alternativos no oficiales que no se encuentran en la zona raíz del DNS oficial.
      • Ejemplos:
        • Cloudflare (1.1.1.1), Google public DNS (8.8.8.8), OpenDNS.
      • Críticas:
        • Recopilación masiva de datos (nada es gratis).
        • Redirección poco eficiente en CDNs.
          • Extensión EDNS Client Subnet (ECS) → problemas de privacidad.

El protocolo DNS

• • • El protocolo DNS consta de dos partes principales:

1. Un protocolo de consulta/respuesta utilizado para realizar consultas contra el DNS.

• Puede ser recursivo o iterativo.

Otro protocolo para que los servidores de nombres intercambien registros de bases de datos (transferencias de zona).

También tiene:

• Una forma para notificar a los servidores secundarios que la base de datos de la zona ha cambiado y se necesita una transferencia de zona (notificación de DNS).
• Una forma de actualizar dinámicamente una información en la zona (DNS Update).

El uso más típico es una simple consulta/respuesta para buscar la dirección IPv4/IPv6 que corresponde a un nombre de dominio.

• • • Consulta/respuesta recursiva (se indica con un flag en la cabecera del mensaje):
      • El servidor, cuando carece de la información solicitada, consulta a otro servidor y retorna la respuesta.

(Ilustración de proceso recursivo con cliente, servidor local y servidores autoritativos).

• • • Consulta/respuesta iterativa (no recursiva, se indica con un flag en la cabecera del mensaje):
      • El servidor, cuando carece de la información solicitada, indica a quién se le puede seguir preguntando.

(Ilustración de proceso iterativo con cliente, servidor local y múltiples servidores autoritativos).

• • • Los clientes suelen solicitar recursividad en las consultas.
      • Es más sencillo para ellos.
    • Pero, aunque un cliente haga la consulta solicitando recursividad, el servidor de nombres, por razones de carga, puede responder de forma iterativa.
    • Por esta razón, en la práctica, las consultas son mixtas.
      • En la consulta, algunos servidores responden recursivamente y otros iterativamente.
    • En el siguiente ejemplo vemos una resolución completa típica en la que suponemos que no se puede beneficiar de entradas en caché preexistentes.

• • • Un usuario de A-HOME desea conectarse al host EXAMPLE.COM (p. ej., un navegador web que acceda a la página http://EXAMPLE.COM).
      • Necesita la dirección IP de EXAMPLE.COM.

(Ilustración del proceso de resolución con cliente, servidor ISP y servidores autoritativos).

1. El resolver de A-HOME envía una consulta DNS a su servidor de nombres local, GW-HOME, para convertir el nombre EXAMPLE.COM en una dirección IP (mensaje 1).
2. Si GW-HOME no tiene la dirección de IP de EXAMPLE.COM en su caché, consulta a otro servidor DNS (recursividad) en el ISP.

• El servidor de nombres del ISP no encuentra respuesta en su caché, pregunta a un servidor raíz (ROOT-SERVERS.NET, mensaje 3).

Los servidores raíz no almacenan información sobre nombres o direcciones, sino que devuelven una respuesta con el nombre y las direcciones de los servidores autorizados del dominio .COM (mensaje 4).

1. El servidor de nombres del ISP manda la petición a un servidor de .COM, por ejemplo, a AGTLD-SERVERS (mensaje 5).
2. Este servidor tampoco tiene la respuesta. Envía como respuesta el nombre y direcciones IP de los servidores de nombres del dominio EXAMPLE.COM (mensaje 6).
3. El servidor de nombres del ISP envía la petición a uno de ellos, por ejemplo, ALANA-SERVERS.NET (mensaje 7).
4. Dado que es un servidor autorizado para el dominio, responde al servidor de nombres del ISP con la dirección IP solicitada (mensaje 8).
5. El servidor de nombres del ISP responde a GW-HOME con la dirección (mensaje 9).
6. GW-HOME ahora puede responder la consulta inicial, dando al cliente las direcciones IPv4 o IPv6 deseadas (mensaje 10).

• • • Desde la perspectiva de A-HOME, el servidor de nombres local pudo responder su solicitud.
    • Sin embargo, lo que realmente sucedió es una consulta recursiva, en la que se realizaron múltiples consultas entre servidores raíz y de TLD, así como servidores DNS adicionales para poder responder la solicitud.
    • Notas:
      • Las consultas a servidores raíz y otros servidores TLD no se realizan en cada momento, ya que las consultas (cuando es posible) se benefician del almacenamiento en caché.
      • En redes muy cargadas, soportar recursividad degradará su rendimiento.
    • Habitualmente, las empresas usan servidores DNS no recursivos o configurados para no reenviar consultas fuera de la red local.
      • En este caso, el servidor DNS del ISP solo da recursividad a clientes autorizados.

• • • Cachés de respuestas:
      • Como hemos comentado, para reducir el tráfico, los servidores DNS intermedios hacen caché de las respuestas recibidas.
        • Evita solicitudes continuas a servidores remotos.
      • Un tiempo de vida (TTL) en cada respuesta indica cuánto tiempo se puede almacenar en caché la información (cuánto tarda en "caducar").
        • Pasado este tiempo, se borra de la caché.
      • Si un servidor no autorizado para el dominio que estamos consultando tiene la respuesta en caché (proveniente de una consulta anterior), responde con la información de su caché y marca esta respuesta como respuesta no autorizada con un flag en la cabecera del mensaje.
        • Indica que la información que devuelve es de "segunda mano", aunque normalmente es precisa.
      • En el ejemplo anterior, si otro cliente del mismo ISP vuelve a consultar la dirección IP de EXAMPLE.COM antes de que pase el TTL segundos, el servidor de nombres del ISP responderá al mensaje 2 con esa información.

Resumen de funcionamiento:

• • • El resolver consulta a un servidor de nombres local.
    • ¿El dominio consultado cae bajo su jurisdicción (es un autorizado para ese dominio)?
      • Sí: devuelve registros del recurso.
        • Respuesta autorizada.
      • No: ¿Lo tiene en la caché?
        • Sí: devuelve registros del recurso.
          • Respuesta no autorizada.
        • No: dos posibilidades.

1. Consulta recursiva (es lo habitual):

• Envía mensaje de consulta a otro servidor (que puede a su vez preguntar a otro servidor, etc.).
• Devuelve la respuesta obtenida.
• Guarda copia en caché durante el "tiempo de vida" del registro.

Consulta iterativa:

• Nos devuelve la dirección de los siguientes servidores a contactar.

Tipos de registros de recursos

• • • Aunque el DNS se usa mayoritariamente para determinar la(s) dirección(es) IP que corresponden a un nombre de dominio, también se puede utilizar para otras cosas:
      • Propósito opuesto (nombre de dominio a IP).
      • Averiguar servidores de correo.
      • Saber si el remitente de un correo es alguien autorizado.
      • Gestión de alias (varios nombres para una máquina).
      • Distribución de carga (un nombre para varias máquinas).
      • Descubrimiento de servicios.
      • Etc.
    • En general, DNS proporciona una función de base de datos distribuida para almacenar información asociada a nombres de dominio.
      • Esta información que maneja DNS se llama registro de recursos (RR).
      • Un nombre de dominio (cada nodo del árbol jerárquico de DNS) puede tener 0, 1 o más RR del mismo o distintos tipos asociados.
    • Cuando el "resolver" consulta un nombre de dominio al DNS, recibe uno o más registros de recursos asociados al nombre en cuestión.
      • Por ejemplo:

1. Un tipo "A", que contiene una dirección IP asociada al nombre.
2. Un tipo "MX", que nos da la dirección IP asociada a un servidor de correo.

La función real del DNS es relacionar los nombres de dominio con los registros de recursos. Un registro de recurso es una tupla de cinco valores:

• Nombre de dominio: es el nombre del objeto referenciado por el RR. Puede ser un nombre de estación o un nombre de dominio. Si se omite este campo, el registro aplica al último nombre usado.
• TTL: es el tiempo de vida del registro (segundos). Define la cantidad de segundos que la información sobre ese registro puede mantenerse en un servidor de caché.
• Clase: define el espacio de nombres (en la práctica, solo se usa IN para Internet). Existen otras clases de registros, pero no se usan comúnmente.
• Tipo: identifica el tipo de RR de acuerdo a la tabla siguiente.
• Valor: es la información específica al tipo de RR.

REGISTRO AXFR  todos los registros de recurso de la zona

dig -t  AXFR @ lab.it.uc3m.es

# 7. Registro MX (nombre Servidor de Correo)

# Consulta los servidores de correo para un dominio.

dig -t MX uc3m.es

# 6. Registro SOA (Inicio de Autoridad) (SERVIDOR PRIMARIO) ( CORREO ELECTORNICO DEL ADMINISTRADOR)

dig -t SOA uc3m.es

# 5. Registro PTR (Puntero para consultas inversas) que maquina tiene determinada ip

# Consulta inversa para obtener el nombre de dominio a partir de una IP.

dig -t PTR 115.139.117.163.in-addr.arpa

# 4. Registro NS (Servidor de Nombres)

# Consulta los servidores de nombres autorizados para un dominio/zona. PARA VER PRIMARIO SOA

dig -t NS it.uc3m.es

# 3. Registro CNAME (Nombre Canónico) si no tiene directamente un registro a sino que apunta a otro dominio si preguntas al locl host

# Consulta el alias de un dominio.

dig -t CNAME www.it.uc3m.es

# 2. Registro AAAA (Dirección IPv6 de un host)

# Consulta la dirección IPv6 de un dominio.

dig -t AAAA www.uc3m.es

# 1. Registro A (Dirección IPv4 de un host) si salen varias es que tiene balance de carga

dig -t A www.uc3m.es

Formato de mensaje DNS

• • • Hay un formato de mensaje DNS básico [RFC6195] que se utiliza para todas las operaciones de DNS:
      • Consultas, respuestas, transferencias de zona, notificaciones y actualizaciones dinámicas.

(Ilustración del formato de mensaje DNS con encabezado y secciones).

• • • El mensaje DNS:
      • Comienza con un encabezado fijo de 12 bytes:
        • ID de transacción (16 bits):
          • Se asocia (relaciona) entre el cliente y lo devuelto al servidor.
          • Permite al cliente relacionar las respuestas con las solicitudes.
        • Indicadores (flags) (16 bits):
          • Ver transparencias siguientes.
        • Cuatro campos de 16 bits:
          • Número de entradas en la sección de preguntas.
          • Número de entradas en la sección de respuestas.
          • Número de entradas en la sección de autoridad.
          • Número de entradas en la sección de recursos adicionales.

• • • Indicadores (flags):
      • QR: 1 bit que indica si el mensaje es una consulta (0) o respuesta (1).
      • OPCODE (4 bits): Define el tipo de consulta.
        • Consulta estándar: 0.
        • Inversa: 1.
        • Notificación: 4.
      • AA: Autoridad (1 si el servidor responde con autoridad sobre el dominio consultado).
      • TC: Indica truncamiento si la respuesta excede los 512 bytes en UDP.
      • RD: Si está habilitado, solicita resolución recursiva.
      • RA: Indica si el servidor soporta consultas recursivas.SI ES AA NO USA RA (AL SER SERV AUTORIZADO NO TIENE QUE UTILIZAR RECURSION PARA OBTENER RESPUESTA)
      • Z: Reservado para futuro uso (debe valer 0).
      • AD: Autenticado.
      • CD: Deshabilita validaciones DNSSEC.
      • RCODE (4 bits): Código de retorno que indica éxito o error.

• • • El encabezado va seguido de cuatro secciones de longitud variable, conteniendo cero, uno o más registros de recursos (RR):
      • Preguntas (sección de consulta).
        • Nombre que se quiere resolver.
        • Tipo de registro que se busca.
      • Respuestas.
        • Respuestas correspondientes a la consulta.
      • Autoridad.
        • Información sobre los servidores autoritativos de la zona.
      • Información adicional.
        • Registros no solicitados (prefetching).
        • Responden a consultas que no habían sido pedidas.

Formato de mensaje DNS

• • • RR en respuestas, registros de autoridad y registros adicionales:
      • Cada registro consta de:
        • Nombre de dominio (cualquier número de bytes, como se ha explicado antes).
          • No necesariamente es el nombre que aparece en la consulta; puede ser un nombre relacionado o una referencia anterior.
        • Tipo (16 bits): A, MX, NS...
        • Clase (16 bits): IN (1).
        • TTL (32 bits): En segundos, especifica cuánto tiempo puede estar en la caché.
        • Longitud de datos (16 bits): en octetos.
        • Datos.
    • Respuestas:
      • En esta sección vienen los RR que responden exactamente a lo que se ha consultado.
    • Registros de autoridad:
      • En consultas iterativas, incluye los registros NS de los servidores a los que preguntar después.
      • En consultas inversas, identifica el servidor autoritativo para el nodo consultado.
    • Registros adicionales:
      • Pre-cargados datos (DNS prefetching).
      • Por ejemplo, si un registro contiene nombres en lugar de datos que se resuelven fácilmente (como las direcciones IP de los servidores en la sección de autoridad), el servidor puede tratar de obtener estos datos por adelantado.

Envío TCP o UDP

• • • DNS tiene reservado el puerto 53 tanto de TCP como UDP.
    • Las consultas se envían en principio por UDP:
      • Si no hay respuesta, se implementa un temporizador de 4 segundos tras el cual se retransmite el mismo ID de consulta.
      • El tamaño máximo del mensaje en UDP es 512 bits.
        • Si la respuesta excede este tamaño, se usa TCP (bit TC = 1).
      • Esto es relevante especialmente para registros grandes o respuestas con muchos registros.
      • En el caso de DNSSEC, debido al tamaño de las respuestas, se prefiere TCP.
    • Recuerda:
      • En la práctica, las consultas DNS sobre UDP son más rápidas.

• • • Cuando un secundario tiene que hacer una transferencia de zonas:
      • Puede hacerla por UDP si es incremental (IXFR).
      • Si es completa (AXFR) puede suponer muchos bytes, se hace por TCP.
    • Esto sucede también cuando debe hacer una transferencia de zonas:
      • Cuando tras el tiempo de actualización indicado en el SOA, vuelve a solicitar el registro SOA del primario y observa que el número de serie se ha aumentado.
      • Entonces recibe un mensaje DNS NOTIFY del primario.

DNSSEC

• • • Inicialmente definido sin tener en cuenta seguridad:
      • RFC 2535 propuso DNS-SEC en 1999.
      • RFC 4033-4035 actualizan en 2005.
    • Se basa en criptografía de clave pública:
      • Cada zona tiene una clave pública y otra privada.
      • Los datos DNS se firman digitalmente:
        • RRSIG: Firma digital.
        • DNSKEY: Clave pública.
    • Asegura:
      • Protección de datos: autenticidad y validez.
      • Protección contra inyecciones: evita datos falsos.
    • DNSSEC no protege contra la denegación de servicio ni protege el tráfico DNS.
    • Requiere compatibilidad entre servidores DNS y protocolos actualizados.
    • Componentes:
      • Se añaden nuevos tipos de RR (RRSIG, DNSKEY, NSEC, etc.).
      • Cada entrada DNS está firmada.

Dynamic DNS (DDNS)

• • • Extensión de DNS para permitir que se pueda añadir, borrar o actualizar entradas:
      • Versión no segura: RFC 2136.
      • Versión segura: RFC 3007.
        • Añade tipo de petición UPDATE.
        • Valor 5 en los 14 tipos de parámetros.
      • Además de la información de actualización se pueden añadir pre-requisitos que verifica el servidor antes de realizar la actualización:
        • Si los RR ya existían o existían previamente.
        • Si el nombre estaba en uso.

El formato de extensión DNS (EDNS0)

• • • El formato de mensaje DNS básico tiene varias restricciones:
      • Tiene campos de longitud fija.
      • La principal es la limitación a 512 bytes cuando se usa con UDP (incluido encabezados UDP e IP).
      • Espacio limitado para indicar tipos de error (el RCODE de 4 bits).
    • Un mecanismo de extensión llamado EDNS0 se especifica en RFC2671:
      • Se utiliza para expandir la seguridad del DNS (DNSSEC, por ejemplo) y en casos de uso más generalizados.
      • Especifica un tipo de pseudo-RR (OPT) que se puede añadir a la sección adicional de una solicitud o respuesta para indicar el uso de EDNS0.
      • Cuando EDNS0 se usa, estos registros pueden estar presentes en una consulta o respuesta.
      • Permite exceder los 512 bytes y contener un conjunto ampliado de códigos de error.
    • Ejemplos EDNS0:

DNS over TLS (DoT)

• • • RFC 7858.
    • Protocolo para enviar las consultas/respuestas DNS sobre TLS.
      • Para aumentar la privacidad (escuchas) y la seguridad (manipulación de la respuesta).
    • Puerto 853.
    • También hay una versión sobre DTLS, pero menos usada en la práctica (RFC 8094).
    • Desde 2019, varios servicios públicos de resolución de DNS (Cloudflare, Quad9, Google, Quadrant Information Security y CleanBrowsing) ofrecen soporte DoT.
    • Críticas:
      • Dificulta control parental (algunos DNS públicos lo ofrecen).
      • Los servidores autorizados (habitualmente) no soportan DoT, con lo que únicamente se cifra salto a salto.
      • Algunos proveedores filtran este tráfico.

DNS over HTTPS (DoH)

• • • RFC 8454.
    • Protocolo para enviar las consultas/respuestas DNS sobre HTTPS.
      • Puede usar HTTPS (1.1) o HTTP/2.
      • Envía los mensajes DNS en la carga útil de un mensaje HTTPS con el tipo MIME application/dns-message.
    • Todavía poco soportado en sistemas operativos, pero cada vez más en navegadores.
      • El navegador no usa el resolver del sistema operativo para hacer las consultas al DNS, sino que envía las consultas por HTTPS usando otro servidor DNS.
    • Soportado cada vez por más servidores DNS públicos.
    • Mismas críticas que a DoT, pero es más difícil de filtrar (es un tráfico HTTPS

SERVICIO DE CORREO ELECTRÓNICO CORREO ELECTRÓNICO

ÍNDICE

1. Introducción.

2. Arquitectura del sistema.

3. Formato del mensaje (RFC 822, MIME).

4. Transferencia mensajes (SMTP, ESMTP).

5. Entrega final (POP3, IMAPv4).

Introducción

• Intercambio de mensajes entre usuarios.
  • Aplicación muy popular.
  • Su introducción en empresas supuso un aumento de productividad del 30 %.
• Historia:
  • Desde hace más de 20 años.
    • Extensión del correo local en sistemas multiusuario
  • Al principio era transferencia de fichero al que se añadía primera línea con dirección destino.
    • El núcleo no tenía estructura interna.
      • Imposible enviar a varios a lo mismo.
      • Imposible enviar mezcla de texto, voz, video.
      • Interfaces de usuario pobres.
  • 1982: propuesta de e-mail de ARPANET.
    • RFC 822: formato del mensaje.
    • RFC 821: protocolo de transmisión.
  • 1984: CCITT borrador ("draft") de X.400.
    • 1988: modificaciones hacia MOTIS (OSI).
  • 1990: RFC 822/821 vence a X.400.
  • Responsable del primer "boom" de Internet.
    • (Cacares 1991): 50% conexiones TCP eran de correo.
    • Hoy en día aproximadamente el 10% tráfico correo.
  • Años 90: mejoras, extensiones y nuevos protocolos.
    • Actualmente ¿crisis por el spam?
• Nos centraremos en el e-mail de Internet.

Arquitectura

• Dos subsistemas:
  • Agente de usuario (UA).
    • Programa para leer y escribir correo.
    • mail, pine, mutt... MS Outlook, Mozilla Thunderbird, Apple Mail... Google gmail.
  • Agente de transferencia de mensajes (MTA).
    • Mueve los mensajes entre máquinas.
    • sendmail, exim, postfix, MS Exchange...
• Estándares involucrados:
  • Formato de mensaje (RFC 822, MIME).
  • A quién se lo manda (DNS MX).
  • Protocolo de envío de mensajes (SMTP, ESMTP).
    • Entre UA origen y MTA, y entre MTAs.
  • Protocolo de entrega final (POP3, IMAPv4).
    • Entre MTA final y UA final.

(Diagrama inferior)

El diagrama muestra la interacción entre UA (Usuario Agente), MTA (Agente de Transferencia de Mensajes) y los protocolos implicados como SMTP, POP3/IMAP4 para la entrega final. Cada parte del flujo se etiquetó con referencias a los estándares como RFC 822 / MIME.

RFC 822: Algunas cabeceras

• De traza (la pone cada MTA que pasa el mensaje):
  • Received: [“from” sending host] [by receiving host] {“with” mail protocol} [“id” msg-id] [“for” address],” date-time received
• De identificación del mensaje (la pone el MTA origen):
  • Message-Id: Únique message id.
• De la UA (UA):
  • Date: día y hora de envío del mensaje.
  • From: dirección origen.
    • La mayoría de los virus falsifican esta dirección.
  • Sender: quién ha enviado el mensaje si es una cabecera Sender:.
  • Reply-To: dirección a la que se responde (si no hay, se responde a la de From:).
  • To: lista de los receptores del mensaje (una o varias direcciones separadas por comas).
  • Cc: receptores en copia, pero el mail se ve su dirección.
  • Bcc: lo mismo, pero oculto.
  • Subject: asunto del mensaje.
• Los usuarios UA o MTAs pueden inventarse sus propias cabeceras no estándar, con nombres que empiecen por X-.
• Las direcciones de correo en las cabeceras pueden tener estos formatos:
  • direcció[email protected]
  • Nombre Apellidos
  • Comentarios entre paréntesis (se ignoran).
• Otras cabeceras:
  • In-Reply-To: (Message-Id al que se responde), References (otros Message-Id relevantes), Keywords.
  • En RFC 2076 hay dos (Status y Fcc:) pensadas para mensajes almacenados en buzones, pero no se pueden usar en mensajes enviados por SMTP.

MIME: Multipurpose Internet Mail Extensions

• Defecto de RFC 822:
  • Sólo admite cuerpo de mensaje NVT ASCII.
    • Solo texto en inglés.
  • Tamaño máximo de línea 1000 caracteres.
• Problemas:
  • Lenguas latinas: acentos, ñ, ¿...
  • Lenguas no latinas (hebreo, ruso, chino, japonés).
  • Imágenes, sonido, video, programas...
  • Enviar varias cosas en un mensaje.
• Otros problemas derivados de limitaciones típicas de implementaciones de MTAs:
  • No admiten mensajes mayores de un tamaño determinado.
    • ¿Cómo fragmentar un mensaje en varios?
  • Algunas borran blancos al final del mensaje.
  • Algunas parten las líneas > 76 caracteres.
  • Algunas convierten en .
  • Algunas convierten en varios blancos.
• MIME incluye mecanismos para resolver estos problemas:
  • Originalmente RFC 1341 (año 1992).
  • Versiones posteriores RFCs 2045-47, 2049, 4288, 4289.

MIME: Nuevas cabeceras

• MIME compatible con RFC 822.
  • El mensaje sigue siendo NVT ASCII.
• Define 5 nuevas cabeceras.
  • Cabecera MIME-Version:
    • Esta cabecera debe estar presente para que un mensaje sea tratado como MIME.
    • Versión actual 1.0
      • MIME-Version: 1.0
  • Otras cuatro cabeceras:
    • Content-Type
      • Define cómo interpretar un objeto en el cuerpo del mensaje.
      • Valor por defecto: text/plain; charset=us-ascii.
    • Content-Transfer-Encoding
      • Define cómo está codificado un objeto.
      • Valor por defecto 7bit (NVT ASCII).
    • Content-Description
      • Texto descriptivo del objeto.
    • Content-Id
      • Valor único que especifica el objeto (para poder referenciarlo).
• Vamos a ver con más detalle las dos primeras.

MIME: Content-Type

• Formato:
  • Content-Type: type/subtype; parameter=value; parameter=value...
  • Los parámetros permitidos dependen del tipo y subtipo.
    • Algunos no tienen definido parámetros, otros sólo parámetros opcionales, otros tienen alguno obligatorio...
• Inicialmente (RFC 1521) definidos siete tipos MIME, cada uno con diversos subtipos.
  • Posteriormente se ha añadido un tipo más y cientos de subtipos.
  • Lista mantenida por IANA
    • (http://www.iana.org/assignments/media-types)

MIME: Content-Type

Página 12

• Tipos predefinidos:

1. text: información textual

• text/plain: texto sin formato
  • Parámetro charset= para especificar tabla de códigos:
    • us-ascii: NVT ASCII (rango 0-127). Valor por defecto.
    • iso-8859-x: Con caracteres en el rango 128-255 codificados según la tabla ISO correspondiente.
• Otros subtipos:
  • text/richtext y text/enriched (obsoletos).
  • text/html: Definido en RFC 2854.
  • text/xml: Definido en RFC 3023 (ver también RFC 6839).

MIME: Content-Type

Tipos predefinidos

Página 13

1. multipart: cuerpo del mensaje formado por varias partes.

• multipart/mixed: partes independientes en el orden especificado.
• multipart/parallel: partes sin orden especificado (pueden verse simultáneamente).
• multipart/alternative: las partes son versiones alternativas del mismo contenido en diferentes formatos.
• multipart/digest: cada parte es un mensaje rfc822 completo (para enviar varios mails en uno).
  • Lista de correo tipo "digest", reenvío de varios mensajes en uno...
• Parámetro: boundary=
  • Cadena de 1-70 caracteres que no debe aparecer en el cuerpo del mensaje.
  • Límite entre partes:
    --boundary 
  • Final del multipart:
    --boundary-- 
• Cada parte del multipart puede llevar sus propias cabeceras Content-Type, Content-Transfer-Encoding, Content-Description y Content-Id.
  • Si no las lleva, toma valores por defecto.

MIME: Content-Type

1. message: el cuerpo es un mensaje o una parte de un mensaje grande fragmentado.

• message/rfc822: mensaje completo.
  • Debe tener al menos From, Subject y To.
• message/partial: mensaje dividido para su transmisión. Parámetros:
  • id= identificador único común a todos los fragmentos.
  • number= número de secuencia de este fragmento (el primero es 1).
  • total= número total de fragmentos.
• message/external-body: el mensaje debe obtenerse de la red.
  • Parámetro access-type= indica cómo se accede (ftp, tftp, anon-ftp, local-file, mail-server).
  • Hay más parámetros.
  • Ejemplo:
    Content-Type: message/external-body; 
     access-type="anon-ftp"; 
     site="bicycle.abc.com"; 
     directory="pub"; 
     name="birthday.snd" 

image: el cuerpo es una imagen.

• image/jpeg, image/gif, image/tiff.

video: el cuerpo es un video.

• video/mpeg, video/m4, video/quicktime.

audio: el cuerpo es un audio.

• audio/basic (formato mono, 8 bit, 8 KHz, ley mu), audio/mpeg (mp3, RFC 3003).

application:

• Está pensado para contenidos que no encajen en otros tipos.
• Datos que tienen que ser procesados por una aplicación antes de ser mostrados al usuario.
  • application/PostScript: el cuerpo es un documento PostScript.
  • application/octet-stream: el cuerpo es datos binarios compuesto por bytes de 8 bits. Parámetro optional:
    • padding= para datos de relleno para hacer múltiplo de 8 bits.
    • type= tipo de datos.
• Otros: application/pdf, application/zip, application/javascript...

model:

• Añadido posteriormente para describir modelados 3D. Poco usado.
• model/vrml.

• Otros tipos y subtipos:
  • Empezando por x-...
  • Registrados en el IANA (RFC 2048).

MIME: Content-Transfer-Encoding

• Si el cuerpo del mensaje no es NVT ASCII, puede dar problemas en MTAs.

• MIME define:

• Dos codificaciones:
  • Permiten transformar un mensaje no NVT ASCII en NVT ASCII.
• Una cabecera (Content-Transfer-Encoding) que puede tomar cinco valores:
  • Tres de ellos indican que no se ha hecho ninguna codificación, por distintas razones:
    • Content-Transfer-Encoding: 7-bit
      • No se ha hecho codificación porque cumple las reglas de RFC 821 (texto NVT ASCII con líneas
    • Content-Transfer-Encoding: 8-bit
      • Líneas
      • No es necesario codificar porque MTAs de origen y destino soportan 8-bit-MIMEtransport (ver ESMTP).
    • Content-Transfer-Encoding: binary
      • Caracteres no NVT ASCII y >1000 caracteres sin .
      • No es legal usarlo con protocolos de transporte actuales (SMTP, ESMTP). Sólo para indicar codificación de mensaje message/external-body.
  • Los otros dos indican que se ha hecho una codificación:
    • Content-Transfer-Encoding: quoted-printable
    • Content-Transfer-Encoding: base64

MIME: quoted-printable

• Objetivo:

• Que el texto codificado siga siendo legible.
• Pensado para textos con pocos caracteres no NVT ASCII (por ejemplo, mensaje en castellano).

• Reglas de codificación:

1. Cualquier byte con valor hexadecimal XY puede representarse en quoted-printable como tres caracteres NVT ASCII: =XY, excepto la pareja de bytes (0x0D0A) cuando representan un final de línea.
2. Los caracteres en el rango 33-126 (0x21-0x7E) se pueden representar directamente en NVT ASCII, excepto el 61 (0x3D, que corresponde al carácter =).
3. El tabulador (0x09) y el blanco (0x20) pueden representarse directamente en NVT ASCII excepto si son el último carácter de una línea (se representan como =09 o =20).
4. Las líneas no pueden ser mayores de 76 caracteres (excluidos ). Si alguna es mayor, debe incluirse un final de línea "blando", esto es, la secuencia = (0x3D0D0A).

MIME: base64

• Objetivo:

• Codificar datos binarios (que no son texto).
• Más eficiente que quoted-printable.

• Reglas de codificación:

• Se introducen bytes relleno al final para que número total bytes sea múltiplo de 3.
• Cada 3 bytes (24 bits) se divide en 4 grupos de 6 bits.
• Cada grupo de 6 bits (valor decimal 0-63) se codifica como un carácter NVT ASCII según la tabla de la transp. siguiente (cada uno ocupará 8 bits).
• Las líneas se fragmentan () para que no sean mayores de 76 caracteres.
• Se añaden al final tantos caracteres = (0, 1 ó 2) como bytes de relleno se hayan introducido inicialmente.

• Ejemplo:

makefile

Copiar código

Content-Type: image/gif
Content-Transfer-Encoding: base64

JVBORw0KGgoAAAANSUhEUgAABVYAAAFYCAYAAACqzXMpAAAqkklEQVR42u2deXRT2d3mZxkbMxMb
b2hyaW7D2c0uVh3AN1s92qRAVvUj9xnXOOLtDRrrEz6sC9hC9exC9e3Cqk2bvVnhCLJb9ncg
[...]

MiAAVf1K0Lu2tmGs8AW1FKFJg4Kc3RhcRn4K4wCmCJ9T3qC1u9URUGCg==

MIME: Consideraciones sobre Content-Transfer-Encoding

• Observar que:

• Esta cabecera aplica al cuerpo del mensaje, no al valor de las cabeceras.
  • Por ejemplo, poner una ñ en un Subject.
• En mensajes multipartes, cada parte puede llevar una codificación distinta.
  • Si no lo lleva, se entiende el valor por defecto (7bit).
• El tipo (Content-Type) no condiciona que se use una determinada codificación.

MIME: Valores no NVT ASCII en cabeceras

• RFC 1342 especifica cómo enviar caracteres no NVT ASCII en el valor de una cabecera.
  • From, To, Subject...
  • Versión actualizada RFC 2047.
• =?charset?encoding?encoded-text?=
  • charset: us-ascii, iso-8859-x
  • encoding: un carácter.
    • B: codificación base64 (igual que se ha visto).
    • Q: codificación quoted-printable.
      • Diferencia: blanco se pone como _.
  • encoded-text: texto codificado.

• Ejemplos:

ruby

Copiar código

Subject: =?ISO-8859-1?Q?Fel=EDz_a=F1o?=
From: =?US-ASCII?Q?Keith_Moore?=  
To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?=  
CC: =?ISO-8859-1?Q?Andr=E9_Filard?= Filard  
Subject: =?ISO-8859-1?Q?N=E9gociations_?G?E9l=E9phant=E9= 
2734BB1IrNickoWLSM1kNQRXZelq3=?= 

S/MIME

• S/MIME (Secure / Multipurpose Internet Mail Extensions) es un estándar para criptografía de clave pública y firmado de correo electrónico encapsulado en MIME.
  • RFC 2633 (1999), versión actual RFC 5751 (2010).
• Proporciona:
  • Autenticación, integridad y no repudio (mediante el uso de firma digital).
  • Privacidad y seguridad de los datos (mediante el uso de cifrado).
• S/MIME especifica el tipo application/pkcs7-mime:
  • La entidad MIME completa se cifra y se inserta en una entidad MIME application/pkcs7-mime.

Funcionamiento del cifrado de correos:

1. El remitente conoce las claves públicas de los destinatarios (certificados X.509).
2. Crea una clave simétrica de sesión.
3. Para cada destinatario del correo:

• Crea una copia de la clave simétrica, cifrada con:
  • La clave pública del destinatario.
  • Su certificado.
  • El algoritmo de clave simétrica usado.

Cifra el mensaje con la clave simétrica. Codifica todo el contenido cifrado en base64.

Firma de mensajes en S/MIME:

1. Creación del resumen:

• Para cada destinatario se crea un resumen del mensaje (hash del contenido).

Firma del resumen:

• El resumen se firma usando la clave privada del remitente.

Inclusión de información:

• Cada firma incluye:
  • La firma del resumen.
  • El certificado del remitente.
  • El algoritmo utilizado.
• Esto se inserta en una entidad application/pkcs7-signature.

Empaquetado del mensaje:

• Todo se empaqueta junto con el mensaje en un multipart/signed.

SMTP: Protocolo de transferencia de mensajes

1. Objetivo:

• Transferencia de mensajes desde UA origen a MTA.
• Transferencia entre MTAs hasta llegar al MTA de destino.

Características:

• Protocolo: SMTP (Simple Mail Transfer Protocol).
• RFC: 821 (actualizada a RFC 2821 y RFC 5321 en 2008).
• Puerto: TCP 25.
• Formato:
  • Conexión establecida → Servidor envía mensaje de bienvenida (en NVT ASCII).
  • Intercambio de comandos y respuestas en NVT ASCII.

Estructura de comandos y respuestas:

• Comandos (origen -> destino):
  • NVT ASCII (similar a FTP, pero con menos comandos).
• Respuestas (destino -> origen):
  • Formato: 3 dígitos + espacio + texto opcional.
  • Ejemplo: 250 message accepted.
  • Significado: Solo es significativo el número (igual que FTP).

Comandos SMTP (obligatorios)

1. HELO

• Identifica al origen ante el destino.

MAIL FROM:

• Comienza la transacción de un correo.

RCPT TO:

• Especifica un destinatario del correo.

DATA

• Inicia el envío del mensaje (RFC 822 o MIME).

QUIT

• Termina la conexión (destino envía OK y cierra).

RSET

• Aborta la transacción actual del correo.

VRFY

• Verifica si existe el usuario especificado.

NOOP

• "No operation" (el servidor responde 200 OK).

Comandos SMTP (opcionales)

1. EXPN

• Confirma si existe una lista de correo específica.

HELP []

• Muestra información sobre comandos disponibles o uno específico.

Comandos obsoletos

1. TURN

• Intercambia los roles de origen y destino (problemas de seguridad).

SEND FROM:

• Envía el mensaje al terminal.

SOML FROM:

• Send or mail: Si el usuario está conectado, se envía al terminal; de lo contrario, se envía por correo.

SAML FROM:

• Send and mail: Envía al terminal y por correo.

SMTP: Respuestas

• Formato:
  3 dígitos + carácter blanco + texto opcional +
  • Todo en NVT ASCII.
  • El cliente solo procesa el código de 3 dígitos.
  • El texto opcional es para interpretación humana.

Clasificación de respuestas SMTP

1. 1yz - Respuesta preliminar positiva

• El comando ha comenzado a ejecutarse.
• Se debe esperar a una respuesta completa antes de enviar un nuevo comando.

2yz - Respuesta completa positiva

• El comando ha sido ejecutado correctamente.

3yz - Respuesta intermedia positiva

• El comando fue aceptado, pero se debe enviar otro comando para completarlo.

4yz - Respuesta completa negativa transitoria

• La acción solicitada no se ejecutó correctamente, pero la causa es temporal.
• El comando puede reintentarse.

5yz - Respuesta completa negativa permanente

• El comando no ha sido aceptado y no debe reintentarse.

Ejemplo de Respuestas SMTP

• 220: Servicio listo.
• 250: Comando aceptado y ejecutado.
• 354: Comenzar a enviar los datos del mensaje.
• 421: Servicio no disponible (error temporal).
• 550: Usuario desconocido (error permanente).

SMTP: Secuencia de comandos

1. Establecimiento de conexión TCP

1. El cliente (C) establece una conexión TCP al puerto 25 del servidor (S).
2. Identificación:

• El servidor envía un mensaje de bienvenida:
  • S: 220 Service ready
  • Error: 421
• El cliente envía su nombre y espera confirmación:
  • C: HELO
  • S: 250 Requested mail action okay, completed
  • Error: 500, 501, 504, 421

2. Envío de correo

1. Dirección origen del correo:

• C: MAIL FROM:
• S: 250 Requested mail action okay, completed
• Fallo: 552, 451, 452
• Error: 500, 501, 421

Direcciones de destino (repetido por cada destinatario):

• C: RCPT TO:
• S: 250 Requested mail action okay, completed
• S: 251 User not local; will forward to
• Fallo: 550, 551, 552, 553, 450, 451, 452
• Error: 500, 501, 503, 421

Envío de datos:

• C: DATA
• S: 354 Start mail input; end with .
• C: Contenido del correo (RFC 822, MIME)
• C: .
• S: 250 Requested mail action okay, completed
• Fallo: 552, 554, 451, 452

4. La fase 3 puede repetirse para enviar varios correos en la misma conexión.

3. Despedida

• C: QUIT
• S: 221 Service closing transmission channel
  • Error: 500

4. Cierre de la conexión TCP

Ejemplo 1: Transacción Normal

vbnet

Copiar código

S: 220 foo.com Simple Mail Transfer Service Ready 
C: HELO bar.com 
S: 250 foo.com greets bar.com 
C: MAIL FROM: 
S: 250 OK 
C: RCPT TO: 
S: 250 OK 
C: RCPT TO: 
S: 550 No such user here 
C: RCPT TO: 
S: 250 OK 
C: DATA 
S: 354 Start mail input; end with . 
C: Blah blah blah... 
C: ...etc. etc. etc. 
C: . 
S: 250 OK 
C: QUIT 
S: 221 foo.com Service closing transmission channel 

Ejemplo 2: VRFY antes de enviar

vbnet

Copiar código

S: 220 foo.com Simple Mail Transfer Service Ready 
C: HELO bar.com 
S: 250 foo.com greets bar.com 
C: VRFY Crispin 
S: 250 Mark Crispin  
C: SEND FROM: 
S: 250 OK 
C: RCPT TO: 
S: 250 OK 
C: DATA 
S: 354 Start mail input; end with . 
C: Blah blah blah... 
C: ...etc. etc. etc. 
C: . 
S: 250 OK 
C: QUIT 
S: 221 foo.com Service closing transmission channel 

Ejemplo 3: Abortar transacción SMTP RSET

vbnet

Copiar código

S: 220 foo.com Simple Mail Transfer Service Ready 
C: HELO bar.com 
S: 250 foo.com greets bar.com 
C: MAIL FROM: 
S: 250 OK 
C: RCPT TO: 
S: 250 OK 
C: RCPT TO: 
S: 550 No such user here 
C: RSET 
S: 250 OK 
C: QUIT 
S: 221 foo.com Service closing transmission channel 

Ejemplo 4: Listas de correo

• Expandir una lista (respuesta multilínea):

makefile

Copiar código

C: EXPN Example-People 
S: 250-Jon Postel  
S: 250-Fred Fonebone  
S: 250 Sam Q. Smith  

• Ejemplo de denegación de permiso para expandir lista:

vbnet

Copiar código

C: EXPN Executive-Washroom-List 
S: 550 Access Denied to You. 

SMTP: Consideraciones sobre RCPT • Los destinatarios del correo los determina el comando RCPT TO, no las cabeceras From, To, Cc, Bcc del mensaje.

SMTP: ¿Para qué el reenvío de mail?

• Teóricamente:
  El UA del origen podría enviar el correo directamente al MTA del destinatario realizando una consulta DNS.
  • Ejemplo: Si el correo es para [email protected]:
    • Se consulta el DNS MX asociado a dominio.es.
    • Si no hay registro RR MX, se consulta RR A e intenta enviar el correo a esa máquina.

• En la práctica, el correo pasa por varios saltos debido a:

1. Configuración de los UAs:

• Suelen estar configurados para enviar todo su correo a un MTA por defecto.

Organización centralizada:

• Todas las MTAs de una organización suelen enviar el correo a una única MTA de salida.
• Esta máquina es la única que puede establecer conexiones TCP 25 al exterior.
• Esto evita que máquinas internas generen spam.

MTA de salida y destino:

• La MTA de salida determina la MTA de destino mediante una consulta DNS RR MX.
• Generalmente, una única MTA recibe todo el correo entrante y lo distribuye internamente.
  • Da una visión unitaria de la organización con direcciones tipo [email protected].
  • Proporciona mayor control ante ataques de spam.

• Si ningún MTA de RR MX responde:

1. Debe reintentar tras al menos 30 minutos.

2. Si sigue fallando, debe reintentar durante 4-5 días.

3. RFC 1123:

• Define los requisitos para los hosts de Internet.
• Este comportamiento también está incluido en RFC 2821/5321.

SMTP: MTAs de reenvío

• Definición:
  Las MTAs intermedias se denominan MTAs de reenvío o MTA Relay.
• Configuración:
  Están configuradas para aceptar:
  • Conexiones de clientes de tu organización para enviar correos (RCPT TO) a cualquier destinatario de Internet.
  • Conexiones de clientes de todo Internet que envían correos (RCPT TO) a destinatarios dentro de la organización.

SMTP: Más consideraciones sobre RCPT

• Escenario inicial:
  En el UA, ponemos como destinatarios:
  To: [email protected], [email protected]

1. ¿Qué pondrá el UA en el RCPT TO?

• Si todo su correo lo manda a un MTA por defecto, se enviará:
  
  vbnet
  Copiar código
  C: RCPT TO:  
  S: 250 OK 
  C: RCPT TO:  
  S: 250 OK 
  C: DATA 
  ...

1. ¿Qué pondrá el MTA Relay en el RCPT TO en el siguiente salto?

• El MTA Relay obtendrá por DNS el RR MX de abc.de, se conectará al puerto 25 de esa máquina y enviará:
  
  vbnet
  Copiar código
  C: RCPT TO:  
  S: 250 OK 
  C: DATA 
  ...
• Cerrará la conexión, obtendrá por DNS el RR MX de uvx.yz, se conectará al puerto 25 de esa máquina y enviará:
  
  vbnet
  Copiar código
  C: RCPT TO:  
  S: 250 OK 
  C: DATA 
  ...

• Detalles adicionales:
  • El mensaje que se envía en DATA será el mismo, excepto la cabecera Bcc: si alguno de los destinatarios estaba en Bcc.
  • Cada MTA destino añadirá su propia línea Received: en el correo.

ESMTP (Extended SMTP)

1. Problemas de SMTP (RFC 821):

• Longitud de los mensajes:
  Algunas implementaciones no soportan mensajes mayores de 64 KB.
• Cuerpo del mensaje:
  Problemas al incluir caracteres no NVT ASCII.
• Temporizadores (timeout):
  Cliente y servidor pueden tener diferentes configuraciones.
• Seguridad:
  Falta autenticación y confidencialidad.

1. Solución: ESMTP (RFC 1425):

• Actualizaciones y RFCs posteriores:
  • RFC 5321: ESMTP
  • RFC 1652 / 6152: Soporte para 8-bit
  • RFC 1870: Soporte para SIZE
  • RFC 2554 / 5248: AUTH (autenticación)
  • RFC 3207: STARTTLS (confidencialidad)
• Compatibilidad hacia atrás:
  • Un cliente que desee usar ESMTP comienza enviando EHLO en lugar de HELO:
    
    makefile
    Copiar código
    C: EHLO varpa.it.uc3m.es 
  • El servidor responde con una lista multilínea de comandos ESMTP que soporta.
  • Ejemplo respuesta:
    
    makefile
    Copiar código
    S: 250-EXTENDED SMTP 
    S: 250-SIZE 
    S: 250-AUTH LOGIN PLAIN 
    S: 250-STARTTLS 
• Si el servidor no soporta ESMTP:
  
  makefile
  Copiar código
  C: EHLO varpa.it.uc3m.es 
  S: 500 Command unrecognized 
  C: RSET 
  S: 250 Reset state 
  C: HELO varpa.it.uc3m.es 
  ...

Extensiones de ESMTP:

• Los comandos MAIL FROM y RCPT TO pueden incluir parámetros adicionales.

ESMTP: Extensiones de seguridad

SMTPS:

• Puerto 465:
  • Negocia TLS automáticamente después de abrirse la conexión TCP, antes de enviar comandos/respuestas SMTP.
  • Estado:
    • Obsoleto (reemplazado por STARTTLS).
    • El puerto 465 ahora está reservado para otra aplicación, pero aún existen servidores y clientes que lo utilizan.

RFC 3207 (STARTTLS):

• Funcionamiento:
  • Durante una sesión SMTP normal, el cliente y servidor negocian TLS para asegurar la conexión.
• Proporciona confidencialidad y seguridad sobre una conexión SMTP existente.

RFC 5248 (AUTH):

• Autenticación del cliente:
  • El servidor ofrece una lista de mecanismos de autenticación soportados:
    • PLAIN, LOGIN, GSSAPI, DIGEST-MD5, CRAM-MD5, MD5.
  • El cliente selecciona uno para autenticarse.

Ejemplo de PLAIN:

• El cliente envía la autenticación en formato base64:
  "authorization-id\0authentication-id\0passwd"
  • Ejemplo simplificado de flujo:
    • Primero, normalmente se habrá ejecutado STARTTLS para cifrar la conexión.
    • El cliente envía los datos de autenticación en base64.

Comportamiento del servidor:

• Si el cliente no se autentica, el servidor puede responder a otros comandos con:
  
  530 Authentication required

SMTP: Medidas contra el spam

El problema del spam:

• Actualmente, 9 de cada 10 mensajes enviados por correo electrónico son spam.
• Para combatir el spam, se han implementado y estandarizado diversas medidas.

Mail Submission:

• Objetivo:
  Los proveedores de Internet limitan el uso de sus MTA Relay a sus propios usuarios.
• RFC 6409 (2011) define el procedimiento Mail Submission:
  • Se implementa usando ESMTP con la extensión AUTH.
  • Se utiliza preferentemente el puerto 587 en lugar del 25:
    • Puerto 587: UA -> MTA (envío de correo por usuario al servidor).
    • Puerto 25: MTA -> MTA (envío entre servidores).
  • El MTA Relay puede comprobar los campos del mensaje para verificar si son correctos.

SPF (Sender Policy Framework):

• RFC 6652 (2012):
  Proporciona una forma de verificación de correos electrónicos mediante DNS.
• Funcionamiento:
  • Cuando una MTA recibe un correo de otra MTA, verifica lo siguiente:

1. Que en el DNS, la IP del MTA que envía el correo corresponde con su nombre de dominio.
2. Si el dominio de la dirección de origen tiene una política de envío de correo definida y esta política coincide con la MTA que envía el correo.

La política SPF se configura mediante registros RR TXT en el DNS.

Ejemplo de SPF:

SMTP: Medidas contra el spam (III)

DKIM (DomainKeys Identified Mail):

• RFC 4870 (2007), actualizado en RFC 6376 (2011).
• Mecanismo de autenticación que permite a una organización responsabilizarse del envío de un mensaje, validable por el receptor.
• Utiliza criptografía de clave pública para firmar electrónicamente correos electrónicos legítimos.
  • Ejemplo de uso: Gmail.
• Protección contra manipulación:
  • Asegura integridad de extremo a extremo entre un módulo firmante y un validador.
• DKIM añade la cabecera "DKIM-Signature" con una firma digital del contenido (cabeceras y cuerpo):
  • Por defecto SHA-256 + RSA, codificando la firma con Base64.

Ejemplo:

css

Copiar código

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 
d=uc3m-es.20150623.gappssmtp.com; s=20150623; 
h=message-id:reply-to:from:to:cc:references:subject:date; 
b=[... Base 64 ...]

SMTP: Medidas contra el spam (IV)

DMARC (Domain-based Message Authentication, Reporting, and Conformance):

• RFC 7489 (2015).
• Protocolo diseñado para proteger contra phishing y suplantación de identidad (spoofing).
• Define políticas que indican cómo manejar correos que no superen verificaciones como SPF o DKIM.

Políticas de DMARC:

• none: Sin acción (solo monitoreo).
• quarantine: Envía los correos no verificados a la carpeta de spam.
• reject: Rechaza directamente los correos no autenticados.

Configuración:

• DMARC se implementa añadiendo un registro DNS que define la política.

Ejemplo de Registro DMARC:

$ dig -t TXT _dmarc.uc3m.es
; ANSWER SECTION:
_dmarc.uc3m.es. 86400 IN TXT "v=DMARC1; 
p=quarantine; rua=mailto:[email protected]; 
ruf=mailto:[email protected]; pct=100; fo=1

Explicación del Registro:

• v=DMARC1: Especifica la versión del protocolo.
• p=quarantine: Envía correos sospechosos a la carpeta de spam.
• rua/ruf: Direcciones donde se envían reportes agregados y detallados.
• pct=100: Aplica la política al 100% de los correos.
• fo: Indica qué incluir en los reportes de fallos.

SMTP: Medidas contra el spam (V)

• DMARC protege tanto a remitentes como receptores:
  • Garantiza que solo correos autenticados puedan enviarse desde un dominio válido.
  • Prevención de ataques de phishing.

Entrega Final

• El destinatario puede leer el mail directamente con un UA en la máquina MTA destino.
• O bien desde otro ordenador con UA (que no necesita tener una MTA), usando un protocolo de entrega final:
  • POP3 (Post Office Protocol)
    • RFC 1081, actual 1939.
    • Protocolo ASCII (al estilo SMTP) que permite:
      • Ver qué mensajes hay en una cuenta.
      • Recoger mensajes del MTA al UA, para leerlos posteriormente.
      • Borrar mensajes.
  • IMAPv4 (Interactive Mail Access Protocol)
    • RFC 1730, actual 3501.
    • Más sofisticado.
    • Deja el correo en el servidor.
    • Mejor cuando se accede desde varios ordenadores.

POP3

• RFC 1081 - Post Office Protocol - Versión 3.
  • Última versión RFC 1939, extensiones en 1957, 2449, 6186.
• Sobre TCP, puerto 110.
• Tras abrir conexión, se recibe bienvenida del servidor:
  • S: +OK POP3 server ready
• A partir de ahí cliente y servidor mandan comandos y responden.

Respuestas:

• S: +OK string
• S: -ERR string

Comandos:

• USER
  • S: +OK
• PASS
  • S: +OK
• STAT
  • Devuelve número de mensajes y tamaño total.
  • Ejemplo:
    
    makefile
    Copiar código
    C: STAT 
    S: +OK 2 320 
• LIST
  • Lista mensajes y tamaño.
  • Ejemplo:
    
    makefile
    Copiar código
    C: LIST 
    S: +OK 2 messages (320 octets) 
    1 120 
    2 200 
    S: . 
• RETR
  • Recupera mensaje indicado.
• DELE
  • Borra el mensaje indicado.
• NOOP
  • No hace nada.
• QUIT
  • Cierra sesión y borra los mensajes marcados.

Ejemplo de sesión POP3:

C: USER mrc 
S: +OK 
C: PASS secret 
S: +OK 
C: STAT 
S: +OK 2 320 
C: LIST 
S: +OK 2 messages (320 octets) 
1 120 
2 200 
S: . 
C: RETR 1 
S: +OK 120 octets 
C: DELE 1 
S: +OK message 1 deleted 
C: QUIT 
S: +OK POP3 server signing off 

POP3 (y IV)

Comandos opcionales:

• TOP []
  • Envía las cabeceras y las n primeras líneas del mensaje msg.
• UIDL [msg]
  • Da un identificador único de mensaje (no cambia, a diferencia del de posición).
    • C: UIDL
    • S: +OK
    • S: 1 whqtswO00WBw418f9t5JxWxZ
    • S: 2 QhdPTR:00WBwP1h7x7
• APOP
  • Permite autenticarse sin mandar el password en claro.
    • S: +OK POP3 server ready
    • C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
    • S: +OK maildrop has 1 message (369 octets)
  • El final del mensaje de bienvenida es el reto.
  • El segundo parámetro de APOP es el MD5 de:
  • La terminal es tu password.
  • En la última versión de la RFC se consideran opcionales tanto APOP como USER+PASS, pero se debe implementar una de las dos.

POP3: Ejemplo

POP3: seguridad

• POP3S:
  • Reservado puerto 995 (se inicia negociación TLS inmediatamente después del establecimiento de conexión TCP), pero se desaconseja en la actualidad.
• STLS:
  • Comando opcional introducido en RFC 2595.
  • Si se acepta, se inicia negociación TLS:
    C: STLS 
    S: +OK Begin TLS negotiation 
     
    ... 
    C: STLS 
    S: -ERR Command not permitted when TLS active 

IMAP4

RFC 1730 - Internet Message Access Protocol - Version 4

• Última versión RFC 3501, diversas extensiones en RFCs 4466, 4469, 4551, 5032, 5182, 5738, 6186, 6858, 7817.
• Sobre TCP, puerto 143.

Características:

• Protocolo mucho más complejo que POP3.
• Gracias al concepto de buzón, permite manejar los mensajes en el servidor y acceder al correo desde varias máquinas.
• Gracias al concepto de ID único de mensaje, permite acceso simultáneo de varios clientes a un mismo buzón.
• IMAP entiende MIME: permite descargar sólo una parte de un mensaje encapsulado MIME.

IMAP4: Buzones

• Los mensajes están almacenados en buzones.
• Buzón de entrada: INBOX.
• El usuario puede crear y destruir buzones (en el servidor).

Respecto al nombre de los buzones:

• Tienen que ser NVT ASCII.
• Pueden estar jerarquizados:
  • Ejemplo: /salida/curas/reales
  • El carácter que separa los niveles de jerarquía puede ser cualquiera.
  • Ejemplo: “/” y “.”.
• El comando LIST nos da la raíz o el carácter usado por el servidor.

El buzón puede tener los siguientes atributos:

• \Noinferiors: no se tiene otros por debajo en la jerarquía.
• \Noselect: no se puede seleccionar (con SELECT).
• \Marked: tiene mensajes nuevos desde la última vez que se seleccionó.
• \Unmarked: no tiene mensajes nuevos desde la última vez que se seleccionó.

IMAP4: Mensajes

• Los mensajes tienen flags que indican el estado de un mensaje:
  • \Seen: leído.
  • \Answered: respondido.
  • \Flagged: marcado como importante.
  • \Deleted: marcado para borrado.
  • \Draft: mensaje en borrador.
  • \Recent: mensajes nuevos desde su llegada.

Dos formas de identificar un mensaje en un buzón (para leerlo, moverlo, etc.):

1. Número secuencial:

• Es el orden del mensaje en el buzón, de orden ascendente.
• Cambia si se eliminan mensajes en el buzón.
• Se utiliza para acceder a todos los mensajes de un buzón:
  Ejemplo: FETCH 1:10 BODY[HEADER] accede a los primeros 10 mensajes.

UID (identificador único del mensaje):

• No cambia aunque se eliminen otros mensajes del buzón.
• El UIDVALIDITY indica que no han cambiado los mensajes en el buzón.
  Ejemplo: FETCH 10 UID.

IMAP4: Comandos y respuestas (I)

• Cuando el cliente se conecta, recibe un mensaje de bienvenida:
  • Puede ser OK, PREAUTH o BYE.
  • Ejemplo:
    S: OK varpa.it.uc3m.es IMAP4rev1 v1.264 server ready

• A partir de entonces, cliente manda comandos:
  • Cada uno precedido de un identificador único llamado etiqueta (tag) y termina con .

• El servidor manda respuestas:
  • Compuestas de:
    • Etiqueta del comando + OK, NO o BAD.
    • Respuesta opcional en una o varias líneas (depende del comando) de resultado que servirá para el cliente.
  • "server completion result": una línea con la etiqueta del comando, la respuesta de OK, NO o BAD, y el nombre del comando y un texto.
  • Ejemplo:
    C: a047 NOOP
    S: a047 OK NOOP completed

IMAP4: Comandos y respuestas (II)

• No es necesario que el cliente espere la respuesta para enviar el siguiente comando.
  • Dos excepciones:

1. Durante la fase de autenticación del comando AUTHENTICATE.
2. Cuando se envía un string literal (cuando termina con {longitud}).

• En estos casos se debe esperar un + del servidor para seguir mandando.

Si se manda algo antes de recibir +, se recibe respuesta BAD.

• El servidor puede mandar las respuestas en distinto orden que los comandos (primero responder a un comando que se mandó después).
• El servidor puede mandar respuestas que no responden a ningún comando (con etiqueta *).

IMAP4: Estados

1. Conexión sin preautenticación (mensaje de bienvenida OK).
2. Conexión con preautenticación (mensaje de bienvenida PREAUTH).
3. Conexión rechazada (bienvenida BYE).
4. Comando LOGIN o AUTHENTICATE.
5. Comando CLOSE o SELECT con éxito.
6. Comando CLOSE, o SELECT o EXAMINE fallidos.
7. Comando LOGOUT.

IMAP4: Comandos

En estado no autenticado

Pág. 72

Para autenticarse:

• LOGIN: envía login y password en claro.
  • Argumentos: .
  • "Server data": ninguna.
  • "Server completion result": OK o BAD.
  • Ejemplo:
    • C: a001 LOGIN SMITH SESAME
    • S: a001 OK LOGIN completed

• Hay otros comandos para autenticarse (transparencia siguiente).
• No es necesario autenticarse si el servidor en mensaje de bienvenida devolvió PREAUTH.
  • Ejemplo:
    • S: * PREAUTH IMAP4rev1 server logged in as Smith

Pág. 73

En estado no autenticado (II)

• Hay otras formas de autenticarse además del comando LOGIN:

• AUTHENTICATE: solicita al servidor un mecanismo de autenticación. Si el servidor no lo soporta, envía error.
  • Argumentos: .
  • "Server data": +.
  • Cliente manda continuación de datos.
  • "Server completion result": OK, NO o BAD.
  • Ejemplo:

• STARTTLS: negociación TLS.

IMAP4: Comandos

En estado autenticado (I)

• SELECT: selecciona un buzón.
  • Argumentos: .
  • "Server data" (en cualquier orden):
    • FLAGS: flags definidos en el buzón.
    • EXISTS: número de mensajes en el buzón.
    • RECENT: número de mensajes nuevos.
    • OK [UNSEEN ]: posición del primer mensaje no leído.
    • OK [UIDVALIDITY ]: identifica el buzón en el cliente (valores únicos).
    • OK [UIDNEXT ]: UID asignado al siguiente mensaje nuevo.
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    vbnet
    Copiar código
    C: a001 SELECT INBOX 
    S: * 18 EXISTS 
    S: * 2 RECENT 
    S: * OK [UNSEEN 12] First unseen message 
    S: * OK [UIDVALIDITY 3857529045] UIDs valid 
    S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 
    S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited 
    S: a001 OK [READ-WRITE] SELECT completed 
• EXAMINE: como SELECT, pero abre el buzón en solo lectura.
• LIST:
  • Argumentos: .
    • Si directorio es "" devuelve el delimitador de jerarquía y nombre del raíz.
    • En nombre significa cualquier cadena de caracteres.
  • "Server data":
    • LIST () "" .
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    vbnet
    Copiar código
    C: a001 LIST "" "*" 
    S: * LIST (\Noselect) "/" "" 
    S: * LIST () "/" "INBOX" 
    S: * LIST () "/" "foo" 
    S: * LIST () "/" "foo/bar" 
    S: a001 OK LIST completed 
• Hay otra forma:
  • SUBSCRIBE: para suscribir un buzón a una lista de buzones que nos interesan.
  • UNSUBSCRIBE: para borrar un buzón de esa lista.
  • LSUB: como LIST pero solo de los buzones que nos interesan.
• DELETE: borra un buzón.
  • Argumentos: .
  • "Server data": ninguno.
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    vbnet
    Copiar código
    C: a683 DELETE foo 
    S: a683 OK DELETE completed 
    C: a684 DELETE foo/bar 
    S: a684 NO Can't delete mailbox with inferior hierarchical names 
• RENAME: cambia el nombre de un buzón.
  • Argumentos: .
  • "Server data": ninguno.
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    makefile
    Copiar código
    C: a682 RENAME foo blurdybloop 
    S: a682 OK RENAME completed 
• Para crear buzones:
  • CREATE: crea un buzón.
    • Argumentos: .
      • Soporta jerarquía mediante /.
    • "Server data": ninguno.
    • "Server completion result": OK, NO o BAD.
      Ejemplo:
      
      makefile
      Copiar código
      C: A003 CREATE owatagusiam/ 
      S: A003 OK CREATE completed 
      C: A004 CREATE owatagusiam/blurdybloop 
      S: A004 OK CREATE completed 
• Para preguntar datos de estado de un buzón:
  • STATUS:
    • Argumentos: .
      • Estado puede ser MESSAGES, RECENT, UIDNEXT, UIDVALIDITY, UNSEEN.
    • "Server data": * STATUS ().
    • "Server completion result": OK, NO o BAD.
      Ejemplo:
      
      makefile
      Copiar código
      C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) 
      S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) 
      S: A042 OK STATUS completed 
      
• Para añadir un mensaje nuevo a un buzón:
  • APPEND:
    • Argumentos:
      • () (opcional)
      • (opcional)
    • "Server data": +.
    • A continuación el cliente manda el mensaje de la longitud indicada.
    • "Server completion result": OK, NO o BAD.
      Ejemplo:
      
      vbnet
      Copiar código
      C: A003 APPEND saved-messages (\Seen) {310} 
      S: + Ready for literal data 
      C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 
      C: From: Fred FooBar  
      C: Subject: afternoon meeting 
      C: To: [email protected] 
      C: Message-Id:  
      C: MIME-Version: 1.0 
      C: Content-Type: TEXT/PLAIN; 
      C:  CHARSET=US-ASCII 
      C: 
      C: Hello Joe, do you think we can meet at 3:30 tomorrow? 
      C: 
      S: A003 OK APPEND completed 

IMAP4: Comandos

En estado seleccionado (I)

• Todos los del estado autenticado, y además:

1. Para buscar mensajes en el buzón:

• SEARCH:
  • Argumentos: .
    • Ejemplo: SINCE, BEFORE, FROM, TO, CC, BCC, SUBJECT, TEXT, etc.
  • "Server data": * SEARCH ...
    • Devuelve 0 o más números de mensaje que cumplen el criterio de búsqueda.
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    sql
    Copiar código
    C: A282 SEARCH SINCE 1-Feb-1994 NOT FROM "Smith" 
    S: * SEARCH 2 84 882 
    S: A282 OK SEARCH completed 
    
    Otro ejemplo:
    
    vbnet
    Copiar código
    C: A283 SEARCH TEXT "string not in mailbox" 
    S: * SEARCH 
    S: A283 OK SEARCH completed 
    
    Otro ejemplo con combinaciones:
    
    vbnet
    Copiar código
    C: A284 SEARCH TEXT "c" HEADER.FIELDS (DATE FROM) 
    S: * SEARCH 23 
    S: A284 OK SEARCH completed 
    

Para descargarse un mensaje:

• FETCH:
  • Argumentos: .
    • Ejemplo: FLAGS, RFC822, BODY, HEADER.FIELDS, etc.
  • "Server data":
    • El contenido del mensaje o del campo solicitado.
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    sql
    Copiar código
    C: A202 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) 
    S: * 2 FETCH (FLAGS (\Deleted \Seen) BODY[HEADER.FIELDS (DATE FROM)] ...) 
    S: * 3 FETCH (FLAGS (\Deleted \Seen)) 
    S: A202 OK FETCH completed 

Para cambiar las flags de un mensaje (por ejemplo, marcarlo como borrado):

• A005 STORE:
  • Argumentos: +FLAGS ().
  • "Server data": * FETCH .
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    makefile
    Copiar código
    C: A203 STORE 2 +FLAGS (\Deleted) 
    S: * 2 FETCH (FLAGS (\Deleted)) 
    S: A203 OK STORE completed 

1. Para borrar permanentemente un mensaje marcado como \Deleted:

• A006 EXPUNGE:
  • Argumentos: ninguno.
  • "Server data": EXPUNGE.
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    makefile
    Copiar código
    C: A202 EXPUNGE 
    S: * 2 EXPUNGE 
    S: * 3 EXPUNGE 
    S: A202 OK EXPUNGE completed 

Para copiar un mensaje en el buzón:

• COPY:
  • Argumentos: .
  • "Server data": ninguno.
  • "Server completion result": OK, NO o BAD.
    Ejemplo:
    
    makefile
    Copiar código
    C: A003 COPY 2:4 MEETING 
    S: A003 OK COPY completed 

Para usar el UID de un mensaje:

• UID:
  • UID SEARCH para obtenerlo.
  • UID COPY / FETCH / STORE para acceder al mensaje por su UID.
    Ejemplo:
    
    makefile
    Copiar código
    C: A003 UID FETCH 4827314:4828442 (FLAGS) 
    S: * 23 FETCH (FLAGS (\Seen) UID 4827314) 
    S: * 24 FETCH (FLAGS (\Recent) UID 4828442) 
    S: A003 OK UID FETCH completed 

Para cerrar un buzón:

• CLOSE:
  • Argumentos: ninguno.
  • "Server data": ninguno.
  • "Server completion result": OK o BAD.
    Ejemplo:
    
    makefile
    Copiar código
    C: A341 CLOSE 
    S: A341 OK CLOSE completed 
• Nota:
  Cuando se hace un SELECT, EXAMINE o LOGOUT, se hace automáticamente un CLOSE.

IMAP4: Comandos

En cualquier estado

1. CAPABILITY: para solicitar al servidor funciones que soporta.

• Argumentos: ninguno.
• "Server data": * CAPABILITY .
• "Server completion result": OK o BAD.
  Ejemplo:
  
  makefile
  Copiar código
  C: A001 CAPABILITY 
  S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI LOGINDISABLED 
  S: A001 OK CAPABILITY completed 

NOOP: no hace nada (suele resetear timer de inactividad).

• Argumentos: ninguno.
• "Server data": puede devolver información de estado del servidor.
• "Server completion result": OK o BAD.
  Ejemplo:
  
  makefile
  Copiar código
  C: A002 NOOP 
  S: * 21 EXISTS 
  S: * 2 RECENT 
  S: * 1 FETCH (FLAGS (\Seen \Deleted)) 
  S: A002 OK NOOP completed 

LOGOUT: solicita finalizar la conexión.

• Argumentos: ninguno.
• "Server data": * BYE.
• "Server completion result": OK o BAD.
  Ejemplo:
  
  makefile
  Copiar código
  C: A023 LOGOUT 
  S: * BYE IMAP4rev1 Server logging out 
  S: A023 OK LOGOUT completed 

IMAP4: Seguridad

• Comando AUTHENTICATE:
  • Permite evitar mandar la información de autenticación en claro.
  • Varios mecanismos soportados (versiones 4, GSSAPI, S/Key).
  • El resto de la sesión IMAP sí va en claro.
• IMAPS:
  • Reservado puerto 993 (se inicia negociación TLS inmediatamente después de establecimiento de conexión TCP), pero se desaconseja en la actualidad.
• Comando STARTTLS:
  • RFC 2595.
  • Este comando inicia la negociación TLS.
  • Con una respuesta CAPABILITY LOGINDISABLED, el servidor puede indicarnos que es indispensable hacer STARTTLS antes de usar el comando LOGIN.

Ejemplo:

makefile

Copiar código

C: a001 CAPABILITY 
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED 
S: a001 OK CAPABILITY completed 
C: a002 STARTTLS 
S: a002 OK Begin TLS negotiation now 
 
C: a003 CAPABILITY 
S: * CAPABILITY IMAP4rev1 AUTH=EXTERNAL 
S: a003 OK CAPABILITY completed 
C: a004 LOGIN joe password 
S: a004 OK LOGIN completed