Resumen

  • RFC 1204 aconsejaba devolver 250 a un USER sintácticamente correcto aunque el nombre no estuviera reconocido. La igualdad de respuesta impedía consultar la existencia de cuentas.
  • PASS 250 sí correspondía a otra afirmación: la contraseña había sido verificada contra el nombre anterior. DATA 354 abría la entrada del cuerpo y el 250 posterior solo acreditaba que el mensaje quedó en la cola local.
  • NOOP 250 hablaba del estado interno del servidor de envío. Sin comando, fase y emisor, el mismo número no distingue privacidad, autenticación, custodia ni salud local.

La ambigüedad no era un fallo del protocolo

Pocas especificaciones explican con tanta claridad por qué una respuesta afirmativa debe ocultar algo. La RFC 1204 definía USER como la presentación del nombre de quien intentaba enviar correo. Para una cadena bien formada, 250 permitía continuar. El texto recomendaba emitirlo incluso si el servidor no reconocía el nombre.

La finalidad era evitar que un cliente probara uno por uno los usuarios de la base. Desde fuera, una cuenta real y una inexistente producían la misma observación. La distinción seguía dentro del servidor hasta la fase adecuada. La respuesta no declaraba “esta cuenta existe”; declaraba “esta entrada puede pasar al siguiente estado sin que yo revele el inventario”.

Eso obliga a leer “aceptado” con su complemento. Se había aceptado el argumento en la conversación, no confirmado el objeto que parecía nombrar. Un sistema de análisis que extraiga solo código y palabra de éxito fabricará una certeza que el protocolo quiso negar.

El registro del RFC Editor conserva su carácter Experimental y la fecha de febrero de 1991. El Datatracker del IETF lo identifica ahora como un documento Legacy, anterior al registro formal de una fuente, sin respaldo del IETF ni posición en el proceso moderno de estándares. Sirve para estudiar la propuesta; no demuestra uso actual ni implantación amplia.

El PC delegaba dos trabajos que no eran uno

La motivación de los autores partía de los ordenadores personales de la época. Según la RFC, sus sistemas operativos no ofrecían autenticación de usuario, pero el correo necesitaba reducir la falsificación del remitente. Un message posting server debía comprobar al usuario y luego presentar el mensaje a un sistema de entrega como Sendmail o MMDF.

El intermediario no absorbía toda la cadena. El cliente controlaba lo que enviaba. El servidor de publicación controlaba su comprobación local y su cola. El sistema de entrega controlaba los intentos posteriores. El protocolo Netix utilizaba TCP, reservaba el puerto 218 y adoptaba la forma de comandos y respuestas de SMTP y FTP.

La RFC 821 había hecho familiar el diálogo bloqueado de comando, respuesta, siguiente comando. RFC 1204 heredó DATA, el cierre por punto y códigos numéricos. Sin embargo, añadió estados propios. El número nunca reemplazaba a la orden que lo provocaba.

La contraseña eliminaba una ambigüedad, no todas

Tras USER 250, el cliente podía emitir PASS. Si el secreto se verificaba como asociado al nombre anterior, el servidor respondía de nuevo 250. Esta vez sí había comparado una relación de credenciales. Una contraseña que no correspondía recibía 530; la sintaxis, la secuencia y los fallos internos tenían respuestas separadas.

Los dos éxitos consecutivos no eran equivalentes. El primero ocultaba si existía un registro. El segundo afirmaba que el servidor había encontrado y validado la asociación necesaria. Esa separación permitía minimizar la información pública sin eliminar la comprobación privada.

Tampoco el segundo código acreditaba una identidad civil o la autoría material del mensaje. No decía quién ocupaba el teclado, si tenía permiso para escribir a un destino concreto o si el contenido era verdadero. Era una decisión del servidor sobre las credenciales configuradas.

La RFC 4954 definiría años después SMTP AUTH mediante mecanismos SASL negociados. También exigiría una configuración capaz de prohibir contraseñas en claro si no había TLS u otra defensa contra la escucha. Esa comparación no moderniza retrospectivamente MPP. Delimita lo que RFC 1204 no especificó y muestra que autenticación y transporte seguro son superficies distintas.

354 abría una ventana; el siguiente 250 cerraba otra

Después de una contraseña válida llegaba DATA. La respuesta 354 significaba que el servidor estaba preparado para aceptar el texto. El parser entraba en modo de cuerpo; aún no podía afirmar que hubiera recibido la secuencia completa.

El cliente enviaba el contenido y el terminador tomado de SMTP. Solo entonces un nuevo 250 significaba que el texto se había colocado con éxito en la cola de entrega. Si un error interno impedía esa custodia, 451 indicaba que no se había encolado.

La cola era un compromiso local más fuerte que la mera disposición a leer. Pero la RFC lo limitaba: el servidor de publicación debía intentar entregar pronto los mensajes aceptados al sistema de entrega. Ese segundo sistema, no el primero, debía tratar los fallos posteriores.

Por eso encolar no equivalía a retransmitir, depositar en un buzón, mostrar en una aplicación o lograr atención humana. El servidor podía responder correctamente dentro de su competencia y seguir sin conocer ninguno de esos resultados.

Una prueba de vida local reutilizaba el mismo número

NOOP no modificaba mensaje alguno. Con 250, el servidor afirmaba solamente que no había encontrado un error interno durante la sesión. El estado de la cola remota, del MTA o del destinatario quedaba fuera.

Así, cuatro líneas con el mismo código podían representar:

  • aceptación sintáctica sin revelar si la cuenta era reconocida;
  • verificación de la relación entre nombre y contraseña;
  • custodia de un cuerpo completo en la cola del posting server;
  • ausencia de error interno conocido en ese servidor.

Reducirlas a un booleano de éxito destruye el modelo. Una prueba útil conserva protocolo, conexión, comando, orden, estado anterior y posterior, componente que responde y objeto afectado. Ese contexto permite saber si se observó una defensa contra enumeración, una autenticación, una entrada en cola o una comprobación de salud.

La arquitectura posterior nombró con más claridad el límite

La RFC 6409 formalizó la presentación de mensajes en el puerto 587. Separó el Message Submission Agent que recibe correo del programa del usuario y el Message Transfer Agent que lo entrega o lo retransmite. También explicó que ambas funciones pueden aplicar políticas de seguridad diferentes.

No hay que convertir la semejanza en una genealogía no demostrada. La RFC posterior no prueba que MPP fuera su origen ni que siguiera desplegado. Su utilidad aquí es conceptual: cuando los roles están nombrados, una respuesta local deja de parecer una promesa del sistema entero.

RFC 1204 conservó esa frontera con pocos comandos. El primer 250 protegía un desconocido, el segundo documentaba una comprobación, el tercero asumía custodia de cola y el cuarto describía salud local. La cifra permanecía igual; la autoridad y el objeto cambiaban.

Fuentes