Resumen

  • RFC 1429 explica cómo LISTSERV DISTRIBUTE podía trasladar un mensaje y su lista de destinos a la red BITNET, que compartía una copia por los enlaces cargados cuando conocía la topología.
  • El documento pide elegir un servidor próximo, comprobar que su archivo de nodos maestros no tenga más de dos meses y consultar al administrador si se prevén más de 10.000 destinatarios diarios. La eficiencia no salía gratis de la palabra DISTRIBUTE.

Eric Thomas eligió una ruta deliberadamente ridícula para explicar el problema: mandar desde California una distribución destinada sobre todo a Estados Unidos a un servidor de Suecia. Su RFC de febrero de 1993 aconsejaba buscar un punto de entrada cercano al público real. El sistema podía ahorrar copias dentro de la red y, aun así, comenzar por un cruce innecesario del océano.

La propuesta sí tenía músculo. El remitente entregaba a LISTSERV el mensaje y una lista de direcciones. La red DISTRIBUTE agrupaba destinos según la topología disponible: una copia atravesaba un enlace muy cargado y las copias adicionales nacían después, cerca de los receptores. Thomas afirmó que el servicio movía entonces entre dos y seis millones de mensajes diarios. Para destinos BITNET bien conectados citó un tiempo habitual de cinco a quince minutos. Esos son los datos publicados por el autor en 1993, con ese contexto.

El punto de entrada necesitaba más que una dirección de correo. La lista de comprobación preguntaba por la conexión real del anfitrión a BITNET. Algunos centros tenían acceso IP T1, pero mantenían una línea alquilada BITNET de 9,6 kilobits. El servidor parecía rápido visto desde una red y estrecho desde la otra. También había que comprobar la versión y el manejo de líneas largas para que el contenido no sufriera al cruzar el sistema.

La otra prueba era de mantenimiento. El archivo Master nodes no debía tener más de dos meses. Thomas advirtió de sitios que no actualizaban sus tablas por falta de personal. Con una topología antigua, el servidor podía decidir mal dónde separar las copias y por qué camino enviarlas. El supuesto ahorro de enlaces dependía de información humana revisada a tiempo.

Para una carga de más de 10.000 destinatarios al día, el RFC pedía autorización al administrador LISTSERV del sitio elegido. Así se podían conocer restricciones y paradas programadas. Algunas universidades reservaban las distribuciones grandes para fuera de las horas punta. La red compartida tenía un operador concreto que podía aceptar o limitar el trabajo.

El mensaje de solicitud también llevaba dos direcciones con deberes distintos. MAIL FROM en la envoltura SMTP debía conducir a una persona capaz de resolver un fallo antes de llegar a LISTSERV. El From del mensaje RFC822 debía recibir avisos de entrega y rebotes posteriores. Poner allí la dirección de envío de la propia lista podía crear un bucle. La automatización no eliminaba la obligación de saber quién recibiría las malas noticias.

Una tarjeta JOB abría la petición, seguida de DISTRIBUTE MAIL, destinatarios con la marca BSMTP y el mensaje. DEBUG=YES mostraba las rutas sin entregar; TRACE=YES informaba mientras entregaba. En el ejemplo impreso, el informe de depuración agrupó tres receptores hacia UGA y dejó dos para envío local. Era una forma de inspeccionar el plan antes de enviar una tirada grande, no una prueba de lectura por los cinco destinatarios.

El truco de LISTSERV era compartir el coste del trayecto, no hacer desaparecer ese coste. La selección del servidor, la línea de entrada, el archivo de nodos y la decisión de su administrador determinaban si la promesa de rapidez resistía la operación diaria.