Resumen

  • La RFC 1425 convirtió EHLO en el punto común para descubrir extensiones SMTP. La respuesta describía una sola sesión y el cliente no podía guardarla en caché para otra.
  • La compatibilidad suponía que un servidor viejo rechazaría EHLO sin cerrar ni estropear el estado, para permitir HELO. La RFC 1651 registró servidores que cortaban la conexión o se negaban a aceptar ese segundo saludo.
  • Registro, anuncio, repliegue ejecutable, aceptación de un comando, transacción de correo y entrega final son hechos diferentes.

SMTP necesitaba incorporar funciones nuevas sin convertir la evolución en una cita obligatoria para todos los servidores del planeta.

El protocolo había prosperado con una conversación contenida: conexión, saludo, HELO, sobre y contenido. A comienzos de 1993, cada ampliación podía añadir su propia negociación y fragmentar ese idioma compartido.

La RFC 1425 propuso una base mínima. Un cliente ampliado abría con EHLO; el servidor enumeraba palabras clave registradas, quizá con parámetros; la conducta de cada extensión quedaba en su propio RFC. El marco coordinaba descubrimiento y nombres. No ordenaba que todos adoptaran todas las funciones.

La declaración caducaba al cerrar la conexión

La norma prohibía conservar la información de un EHLO exitoso. Si el cliente necesitaba conocer las extensiones, debía preguntar de nuevo al inicio de cada sesión SMTP.

Un dato de ayer no tenía autoridad hoy. El mismo nombre podía llevar a otro proceso, otra configuración, otra ruta o un servidor en mantenimiento. La capacidad debía declararse dentro del canal donde se usaría.

El éxito se expresaba con 250 y confirmaba un estado inicial: no había transacción activa y las tablas y búferes estaban limpios. La respuesta multilínea ofrecía las palabras clave. Las públicas, sin prefijo X, correspondían a especificaciones registradas; las locales usaban el convenio X de la época.

Esa lista no equivalía a ejecución. El cliente tenía que elegir una extensión, enviar la sintaxis definida para ella y obtener la respuesta específica.

La RFC 1426 separa bien los peldaños. Encontrar 8BITMIME en EHLO sucede antes de pedir BODY=8BITMIME en MAIL FROM; aceptar ese comando sucede antes de DATA. La custodia de los octetos es otra tesis. Aquí basta observar que anuncio y uso no son la misma prueba.

La ruta de compatibilidad dependía del estado vivo

Los clientes nuevos tenían que conversar con servidores limitados a la RFC 821. La RFC 1425 esperaba que el servidor desconociera EHLO, devolviera un error y permaneciera disponible. El cliente podía reiniciar o enviar HELO y continuar con SMTP clásico.

Era una salida elegante: la negativa no imponía una actualización ni convertía al otro en infractor. Ambos regresaban al conjunto de reglas que compartían.

Sin embargo, el dibujo daba por supuestos varios hechos: el canal debía seguir abierto; el comando desconocido no debía corromper el estado; RSET o HELO debían llegar a una máquina preparada para procesarlos.

La gramática podía exigirlos. Solo el programa en marcha podía demostrarlos.

La sucesora incorporó la evidencia incómoda

En julio de 1994, la RFC 1651 sustituyó a la RFC 1425 y añadió una sección para servidores implementados incorrectamente.

Algunos cerraban el canal SMTP al recibir EHLO, antes o después de contestar. Eso contradecía la regla de RFC 821 que reservaba el cierre normal para QUIT, pero la contradicción no mantenía vivo el socket.

El cliente debía observar el canal, no solo interpretar el código. Tras el cierre, tenía que decidir si podía cumplir la operación sin extensiones. Si podía, abría una conexión nueva y usaba HELO. La segunda conexión no prolongaba la primera; tenía identidad, estado y resultado propios.

Otros servidores no cortaban, pero rechazaban HELO después de rechazar EHLO. A veces funcionaba insertar RSET. Incluso ese remedio podía recibir 503 Bad sequence of commands, que la RFC permitía ignorar en esa recuperación concreta.

La RFC 1869, publicada en 1995, conservó la advertencia. La desviación observada quedó dentro de la memoria del estándar.

No es una derrota de la especificación. Es el momento en que una especificación acepta que su estado válido y el estado desplegado no eran idénticos. La experiencia corrigió el mapa.

Un repliegue contiene varias historias

“ESMTP no disponible; SMTP funcionó” puede esconder dos conexiones y una cadena de resultados.

La conexión inicial, el 220, el envío de EHLO, la respuesta o el cierre, el RSET, el HELO, la aceptación del sobre, DATA, la responsabilidad del relé y la entrega deben conservarse por separado. Un reintento exitoso no vuelve continua la sesión rota. Una palabra clave anunciada no garantiza el comando. La aceptación del contenido no garantiza que alguien lo lea.

Por eso la prohibición de caché es central. La capacidad no era un atributo permanente de un host. Era una afirmación situada en una sesión. Al terminar el canal terminaba su contexto.

La capa mínima trasladó el coste

La RFC 1425 advertía que los protocolos con pocas opciones tienden a difundirse y los cargados de opciones a oscurecerse. Dejó una superficie de descubrimiento pequeña y separó el comportamiento de cada extensión.

El servidor antiguo no tenía que migrar en una fecha común. El cliente interesado en la máxima entrega asumía respuestas multilínea, capacidades caducadas, cierres, reconexiones y excepciones de estado.

El registro daba significado al nombre, pero no instalaba código. El servidor elegía localmente sus extensiones; el cliente elegía una vía compatible en la sesión. La adopción era voluntaria y la compatibilidad, ejecutada.

La flecha del documento describe la transición válida. La traza muestra si alguien la recorrió.