Protocolos de correo: SMTP - Nobbot

Protocolos de correo: SMTP

SMTP

Una vez vistos POP3 e IMAP, el último gran protocolo de correo electrónico que nos queda por explicar es SMTP. Simple Mail Transfer Protocol es el protocolo utilizado para enviar correos. Pero no solo entre nuestro cliente y nuestro servidor de correo, sino que también es el culpable de transmitir ese mensaje entre los diferentes servidores hasta llegar a su destino.

Siguiendo una buena analogía con el correo convencional, podemos seguir el camino que haría un paquete enviado internacionalmente: primero lo llevamos/enviamos a nuestra oficina local de correo, esta lo llevará a la provincial y de aquí a la nacional. Luego viajará en avión u otro transporte al país de destino, será enviado a la región correspondiente, a la oficina local de la ciudad que sea y finalmente a la casa de destino. El email funciona de manera muy parecida, y el idioma que hablan todas esas entidades resulta ser SMTP, salvo el último paso, que utilizaría POP o IMAP (tendríamos que ir a nuestra oficina local a recoger el correo).

En SMTP, los clientes finales (los usuarios) se llaman MUAs (Message User Agent) y las máquinas intermedias se llaman MTAs (la T es de Transfer). A la primera MTA que el cliente envía su email se le denomina MSA (la S es de Sending), y a la última que lo recibe y lo envía al cliente de destino se le denomina MDA (la D es de Delivery). Este galimatías de letras os puede ser útil para no perderos en el resto del artículo.

Esquema del protocolo de correo SMTP

Como hemos dicho, el mensaje pasará de oficina a oficina hasta llegar a la oficina central de la organización, podéis pensar en ellos como subdominios que suben de nivel pero no tiene por qué ser así. Desde ese MTA se hace una petición DNS para obtener los registros MX o, en su defecto, los A del dominio de destino, y conseguir las IP del servidor de correo de destino. Esta petición la podría hacer sin ningún problema el cliente inicial, pero por razones de seguridad, filtrado y uniformidad se prefiere que todo el email de una organización sea pueda controlar por un punto central.

El puerto estándar en el que trabaja SMTP es el 25, abriendo una conexión TCP al servidor a ese puerto. Este puerto es el obligatorio para que las máquinas intermedias (MTAs) hablen entre sí, pero para la conexión entre el cliente (MUA) y su servidor de correo (MSA) pueden usar otro puerto. Este es el caso de Gmail, que requiere de autenticación TLS/SSL y por tanto admite usar los puertos 465 ó 587. Al igual que en el resto de protocolos vistos, una vez se abre esa conexión, el cliente empieza a hablar en ASCII con el servidor, enviando comandos y recibiendo respuestas.

Los comandos son realmente muy pocos, solo hay 8 que se deben implementar obligatoriamente y de esos solo se suelen utilizar 5, casi siempre en el mismo orden. Primero se inicia la comunicación con un HELO que identificará al cliente, seguirá luego un MAIL FROM: con el email de origen, uno o varios RCPT TO: con los emails de destino especificados uno por uno, un DATA con el contenido del mensaje y finalmente un QUIT para cerrar la conexión.

Transcripción de una comunicación de ejemplo usando SMTP

En cada uno de esos pasos el servidor contestará con el estado de la petición, de una manera muy similar a los códigos de HTTP (¿os suena el Error 404, Error 500, etc?). Por supuesto no tenemos por qué mandar únicamente un email en cada conexión, podemos enviar cuántos queremos simplemente repitiendo los MAIL/RCPT/DATA en ese orden.

Este modo de funcionamiento tiene un fallo bastante severo, culpable de que hoy en día el spam campe por sus anchas y el phishing sea posible: no hay autenticación por ningún lado. Con el comando MAIL FROM: podemos especificar cualquier dirección de origen, y también podemos cambiar el contenido del mensaje para reflejar la dirección que queramos. Tranquilamente podemos conectarnos a la MTA de un servidor como el de Yahoo! y decidle que somos bill@microsoft.com, que tendrá que creernos.

Para paliar esta y otras cuestiones se mejoró este protocolo creando ESMTP (Enhanced STMP), una especie de evolución de STMP que admite extensiones. Su funcionamiento es calcado, pero al principio empieza la conexión con un EHLO en vez de un HELO, para intentar explicar que se quiere usar ESMTP. Si el servidor no lo entiende daría un error, se resetearía la conexión y se intentaría empezar una comunicación usando SMTP.

Al iniciarse una conexión ESMTP, el servidor que entienda este protocolo deberá enviar una lista con las opciones que soporta. Por ejemplo, para autenticarse tenemos SMTP-AUTH, y para conseguir una conexión segura cifrándola tenemos STARTTLS. Las extensiones estándares son bastantes y variadas, pero podemos usar otras no estándares si las comenzamos con la letra X.

Gmail permite sacarle algo de partido a ESMTP al verificar los mensajes de Paypal/Ebay

Sin embargo, es poco práctico reemplazar la gran base de servidores SMTP instalados para que soporten SMTP-AUTH. Así que el control del spam no puede pasar por ese requisito, de hecho aún usándolo habría varios fallos de seguridad que los spammers podrían explotar. En general las extensiones relacionadas con las seguridad se vienen utilizando entre la comunicación inicial entre el cliente y su servidor de correo, con algunas notables excepciones como la que ves en la imagen superior.

Aquí dejamos el capítulo de SMTP, el protocolo que nos ayuda a entender cómo viajan los emails por Internet, y que nos permite visualizar los problemas técnicos que causan los problemas que tenemos hoy en día con el email. Ya no hay más protocolos interesantes por comentar, pero aún queda un aspecto técnico del email que merece la pena explicar la próxima semana: su formato. ¿A alguien le suena MIME?

Más información | Wikipedia

  • Esta serie de artículos sigue tan interesante como empezó. ¡Que no pare la cosa!

  • Jaime

    De verdad, super interesante, bien resumido, faltan buenos index.

    De 10!

  • Perfectamente explicado, razonado, se nota que Victor Pimentel es un gran informático !

    Gracias por compartir tus conocimientos y tiempo !