Resumen

  • RFC 784 describió un despachador de correo en TOPS20 que consultaba las capacidades de cada host para elegir MTP sobre TCP, MTP sobre NCP, el método anterior FTP sobre NCP u otra ruta especial.
  • RFC 785 definió dos archivos por mensaje: el texto quedaba en uno; el otro contenía remitente, rutas de destinatarios y un puntero al texto. El despachador podía cambiar la lista de pendientes sin duplicar la carta.

Enviar una carta a cuatro personas parece un asunto de cuatro direcciones, no de cuatro versiones del texto. Algunos sistemas de correo antiguos fabricaban una copia por dirección. Suzanne Sluizer y Jon Postel explicaron en julio de 1981 cómo evitar esa pequeña industria editorial. Su RFC 784 sobre una implementación de MTP para TOPS20 en ISI ponía el mensaje en un archivo y el trabajo de entregarlo en otro. La hoja de ruta recibía las tachaduras; la carta seguía siendo la misma.

Había buenas razones para separar ambas cosas. La implementación, escrita en BLISS-10, se estaba construyendo para enviar y recibir por TCP y por el anterior NCP, con conexiones hacia otros sistemas postales. Los programas con los que la gente redactaba mensajes y los receptores de red creaban archivos en los directorios de usuario. Un despachador en segundo plano los enviaba por los canales disponibles. Una versión de uso inmediato podía intentar el envío si el canal necesario estaba libre. La tabla de capacidades del host decía si el destino aceptaba MTP por TCP, MTP por NCP o el viejo FTP por NCP.

Otra tabla cubría rutas particulares, como el sistema creado por UCL para llegar a hosts en Inglaterra.

Un mensaje con varios destinatarios podía seguir varios caminos a la vez. El archivo de control guardaba los datos de entrega y apuntaba al archivo del texto, que incluía su cabecera RFC 733. Cuando una ruta funcionaba, el despachador podía marcar o quitar al destinatario servido. Si otro canal fallaba o seguía ocupado, su destinatario permanecía en la lista. El archivo del mensaje se leía para el reparto y, al terminar el proceso local, acababa renombrado o eliminado. La hoja de control cambiaba según el trabajo realizado. La prosa del remitente tenía mejores cosas que hacer que reescribirse por cada puerta cerrada.

La RFC 785, dedicada a la definición de esos archivos, dejó el procedimiento en líneas concretas. FILE: señalaba el nombre completo del archivo de texto, FROM: indicaba al remitente y cada TO: añadía una ruta de destino. En el segundo archivo quedaban cabecera y cuerpo. Sus autores compararon el par con sistemas anteriores que creaban N copias del texto para N direcciones de los campos To, Cc y Bcc. La nueva interfaz pedía dos archivos con independencia de cuántos nombres estuvieran en la lista. El sobre y el contenido tenían tareas distintas.

La RFC 786 enseñaba otro mostrador: la interfaz de MTP con NIMAIL. Incluía ejemplos de conversión entre direcciones con signos de porcentaje y rutas de MTP. Los caminos del correo no solo variaban por transporte; los sistemas vecinos escribían las direcciones de manera diferente. El despachador necesitaba saber qué salida usar y qué dirección entendería quien recibiera el paquete de archivos.

Sluizer y Postel describieron piezas que estaban creando, piezas que esperaban que otros adaptaran y tablas que aún había que preparar. RFC 784 es un plan de implementación concreto, acompañado por la interfaz precisa de RFC 785. Lo que revela ya es la lógica de la cola: el destinatario que espera conserva su lugar sin detener necesariamente a los demás. Una lista puede llevar varias historias de progreso aunque el mensaje tenga un solo cuerpo.

Es una oficina de correos fácil de imaginar. La carta descansa en la mesa, una ficha registra las direcciones y el empleado sabe qué puerta conduce a cada host. En 1981 las puertas se llamaban TCP, NCP y FTP sobre NCP. Cuando una no abría, el nombre seguía escrito en la ficha. Las otras rutas podían avanzar. La solución consistía en mover la ficha, no la máquina de escribir.