Resumen

  • La revisión de agosto de 1982 definió SMTP como una conversación fiable sobre un flujo, capaz de retransmitir correo aunque los extremos no compartieran el mismo servicio de transporte.
  • MAIL aportaba una ruta de retorno y RCPT una o varias rutas de destinatario; RFC 822 normalizó aparte el formato del texto, por lo que una sesión aceptada no demuestra que el mensaje llegara al buzón o se leyera.

Un correo puede cruzar una frontera de red sin que el mensaje sepa qué red lo transportó. Ese es el problema de diseño visible en la especificación Simple Mail Transfer Protocol que Jonathan B. Postel publicó en agosto de 1982. RFC 821 no exigía un subsistema concreto de transmisión. Pedía un flujo fiable y ordenado, y definía cómo intercambiaban comandos y respuestas los procesos SMTP.

El relé no era un añadido accidental. Si el host remitente y el destino compartían un servicio de transporte, el emisor podía contactar directamente con el proceso SMTP receptor. Si no, uno o varios servidores intermedios podían unir sus entornos de transporte. Postel precisó la escala: un servicio de transporte podía abarcar una red, varias redes o una parte de una red. “Red” y “entorno de transporte” no eran casillas equivalentes.

La transacción hacía visible el traspaso. El emisor abría un canal bidireccional y el receptor contestaba. MAIL iniciaba la operación con una ruta inversa, útil para devolver avisos de no entrega. Cada RCPT indicaba una ruta de destinatario y podía repetirse. Después, DATA llevaba el mensaje. Las respuestas numéricas mostraban aceptación o fallo en cada paso. La envoltura SMTP transportaba instrucciones de entrega distintas del texto del correo.

La RFC 822, publicada ese mismo mes, ayuda a separar las capas. Establecía el formato de los mensajes de texto de ARPA Internet; RFC 821 describía la conversación de transferencia. Una cabecera From: pertenecía a la representación del mensaje, mientras MAIL FROM formaba parte de la transacción SMTP. Confundirlas convierte una dirección escrita en el texto en supuesta prueba de ruta o de decisión de entrega, algo que ninguna de las dos especificaciones garantiza.

RFC 821 fue una revisión, no el nacimiento de SMTP. Su encabezado reemplaza RFC 788, 780 y 772; RFC 788 ya había especificado SMTP en noviembre de 1981. El plan de transición RFC 801 menciona el servicio SMTP al hablar del cambio de red, pero no ofrece cifras de adopción ni mediciones de entrega al usuario. La fecha de una versión revisada no indica cuándo la instaló cada host.

El modelo tampoco se limitaba a TCP. Los apéndices de RFC 821 describen servicios de transporte distintos, entre ellos NCP, TCP y NITS; el apéndice de TCP asigna a SMTP el número de socket 25. Ese dato concreta el protocolo, pero un puerto abierto no demuestra que exista un servicio operativo. Hacen falta un servidor activo, comandos aceptados, rutas válidas, una transacción de datos y procesamiento local tras la conexión.

La contribución histórica fue una frontera reutilizable. SMTP definió una conversación común para transferir correo y permitió que relés conectaran entornos diferentes; el formato del mensaje y el comportamiento del buzón local seguían siendo preguntas separadas. Desde la Nota 64 de Heng Lu, el diseño sirve como ejemplo de una especificación común que cubre la interoperabilidad necesaria y deja el transporte y el despliegue a los sistemas que la ejecutan. Es una lente analítica, no una intención atribuida a Postel.

Sources