Resumen

  • RFC 821 ofrecía tres órdenes opcionales que incorporaban la presentación en terminal, el depósito en buzón o las dos cosas a la transacción SMTP.
  • Cada una definía el éxito de forma distinta: SEND dependía del terminal, SOML aceptaba cualquiera de los dos destinos y SAML dependía del buzón aunque también intentara mostrar el mensaje.
  • Un relevo MX podía conocer la ruta sin controlar la pantalla del usuario; los estándares posteriores declararon obsoletas esas órdenes y conservaron solo una compatibilidad limitada.

Tres maneras de llegar antes de enviar el cuerpo

En un host compartido de 1982, el destinatario podía estar conectado y admitir mensajes en su terminal. El cliente SMTP remoto abría la sesión y, en lugar del MAIL ordinario, escogía uno de tres verbos.

SEND exigía entrega al terminal; si el usuario no estaba activo o rechazaba esos mensajes, el servidor podía responder con un fallo temporal para ese destinatario. SOML, Send Or MaiL, buscaba el terminal y utilizaba el buzón si el usuario no estaba disponible. SAML, Send And MaiL, intentaba la pantalla cuando procedía y guardaba siempre el contenido en el buzón.

El RFC 821 no los trató como metadatos decorativos. Cada orden iniciaba una transacción, antes de RCPT y DATA. El emisor seleccionaba el comportamiento de entrega antes de proporcionar destinatarios y texto.

Así, el transporte debía interpretar si una persona estaba presente, si aceptaba ser interrumpida y si una aparición momentánea o una copia persistente constituían la entrega.

La palabra «éxito» no significaba lo mismo

Un SEND tenía éxito solo cuando los datos llegaban al terminal. No creaba por sí mismo una copia de respaldo. En SOML, terminal y buzón eran alternativas: bastaba uno. En SAML, la escritura en el buzón era obligatoria y la pantalla era adicional; el criterio de éxito pertenecía al buzón.

Por tanto, un SEND satisfactorio podía carecer de custodia duradera. Un SOML satisfactorio no revelaba necesariamente qué rama se había completado. Un SAML satisfactorio probaba la rama persistente, pero no que el usuario hubiera visto el destello en pantalla.

La gramática reconocía una diferencia real entre llamar la atención y conservar información. La tensión estaba en el reparto de autoridad: el emisor escogía el verbo, pero el destinatario sufría la interrupción y el host receptor debía sostener la promesa.

La presencia era local y momentánea

RFC 821 vinculaba la entrega al terminal a dos hechos: el usuario estaba activo en ese host y aceptaba mensajes de terminal. Ninguno era un atributo permanente de la dirección.

La dirección seguía siendo válida cuando la persona cerraba sesión, cambiaba de máquina o modificaba su preferencia. La ruta seguía funcionando cuando el host que aceptaba el correo ya no gobernaba la sesión interactiva. Incluso durante una transacción, el estado podía cambiar entre la respuesta al destinatario y la llegada del cuerpo.

El cliente podía solicitar SEND, no declarar que el destinatario estaba presente. Que un servidor anunciara la orden demostraba conocimiento del protocolo, no consentimiento o disponibilidad de una persona concreta.

MX separó la ruta de la pantalla

El RFC 1123 hizo opcional implementar SEND, SOML y SAML tanto para emisores como para receptores. Su observación sobre MX señala la fractura decisiva.

Un intercambiador de correo puede aceptar en nombre del destino y saber cómo reenviar el mensaje, pero carecer de acceso directo al terminal del usuario. Para un destinatario posterior a SEND, podía responder 251 User Not Local y advertir de una posible entrega diferida.

La accesibilidad de ruta significaba poder asumir y continuar el correo. La accesibilidad de presentación significaba controlar la superficie donde el usuario estaba activo. Un MX podía poseer la primera y no la segunda.

La red distribuida de almacenamiento y reenvío podía repartir responsabilidad sobre el mensaje; no podía repartir automáticamente autoridad sobre la atención humana.

EHLO descubría una capacidad, no una presencia

Cuando el RFC 1425 creó el modelo de extensiones SMTP, el registro inicial enumeró las tres órdenes como servicios opcionales y reutilizó sus nombres como palabras clave EHLO.

El cliente podía dejar de adivinar si el servidor entendía el verbo. Seguía sin saber si el usuario estaba conectado, si aceptaba interrupciones, si el servidor era final o si la pantalla llegaría a mostrar el contenido.

Un indicador de capacidad puede convertirse con demasiada facilidad en un botón verde y después en una promesa. EHLO solo describía la gramática disponible. No era un servicio de presencia.

La compatibilidad sobrevivió a la pérdida de centralidad

En 2001, el RFC 2821 ya llamaba obsoletos a SEND, SAML y SOML. Señalaba que rara vez habían sido implementados y que los cambios en las estaciones de trabajo y la aparición de otros protocolos podían haberlos vuelto innecesarios.

El estándar no borró la historia de golpe. Los clientes no debían ofrecer estos servicios. Los servidores aún podían implementarlos, siempre que respetaran el modelo del RFC 821 y publicaran los nombres en EHLO.

El RFC 5321 mantiene ese arreglo. Los verbos antiguos siguen siendo reconocibles, pero el SMTP normal gira alrededor de MAIL y del traspaso formal de responsabilidad cuando el servidor acepta los datos.

Esa custodia es una obligación registrable: entregar después o informar del fallo. No pretende saber si unos ojos miraban una pantalla en un instante concreto. La obsolescencia redujo la afirmación del transporte sin romper toda compatibilidad heredada.

IANA conserva vocabulario, no estadísticas de uso

Los registros SMTP de IANA todavía contienen SEND, SOML y SAML, sus referencias al RFC 821, la nota de obsolescencia y la prohibición de utilizarlos para Message Submission.

El registro coordina nombres interoperables. No demuestra cuántos sistemas los ejecutan hoy, si un destinatario está presente ni si una presentación específica tuvo éxito.

Capacidad, presencia, consentimiento, visualización, almacenamiento y responsabilidad son hechos separados. El SMTP temprano unió varios en una elección de transacción. El SMTP posterior no resolvió la atención humana: dejó de prometerla desde el centro del transporte.

Llegar antes no significaba llegar mejor

En un conjunto pequeño de hosts estrechamente acoplados, las tres órdenes eran comprensibles. SOML tenía una degradación sensata; SAML preservaba una copia. Los diseñadores reconocieron que mostrar y guardar no eran iguales.

La escala decidió qué capa debía gobernar cada cosa. Con más relés, estaciones heterogéneas y agentes de usuario separados, el transporte podía controlar colas y custodia, no la pantalla actual ni la voluntad de ser interrumpido.

Una pantalla puede iluminarse ahora y no dejar rastro. Un buzón silencioso puede abrirse después y conservar una obligación. El mensaje que ganó la carrera contra el buzón no siempre encontró un lugar donde quedarse.

Fuentes