Resumen

  • Según el relato que Eric Allman publicó en 1994, el trabajo principal en Sendmail se detuvo después de febrero de 1987 y se reanudó en julio de 1991, cuando ya se habían acumulado variantes de proveedores y colaboradores.
  • Allman explicó su regreso por varias razones: los cambios de Berkeley, la divergencia entre versiones y extensiones de SMTP que, a su juicio, no llegaban a la mayoría de las implementaciones.
  • Sendmail 8.6.6 admitía algunas extensiones y otras solo parcialmente. La publicación del código permitió examinar ese límite, pero no demostró adopción ni cumplimiento completo.

Una pausa larga se convirtió en un problema de versiones

Sendmail ya formaba parte del entorno Unix de Berkeley antes de convertirse en producto de una empresa o en emblema de los debates sobre la economía del software abierto. La biografía de Internet Hall of Fame cuenta que Eric Allman desarrolló delivermail y Sendmail en la Universidad de California, Berkeley, mientras trabajaba en INGRES, y que ambos se distribuyeron con BSD. Ese contexto ayuda a entender el valor del código público: quienes construían sistemas podían examinar y compilar el encaminador de correo dentro de su propio entorno.

El artículo de Allman de 1994, «Changes in Sendmail Version 8», precisa lo que ocurrió después. El trabajo importante en Sendmail se detuvo en la práctica tras febrero de 1987 y se reanudó activamente en julio de 1991. Durante el intervalo, otras personas ofrecieron un apoyo mínimo, mientras proveedores y colaboradores externos mantenían variantes. Allman enumeró varios motivos para volver: Berkeley necesitaba cambios de correo para su estructura de subdominios y para 4.4BSD; había reseñado el libro de Sendmail de Bryan Costales; quería unificar versiones divergentes; y las normas SMTP habían cambiado.

Son varios motivos, no una historia con un único detonante. El código debía acompañar una nueva versión de BSD, reconciliar ramas distintas y responder a cambios del protocolo. Allman escribió que IDA-Sendmail había pasado de ser un conjunto de archivos de configuración a una colección sustancial de parches, utilizada ampliamente por quienes compilaban sus propias fuentes. También sostuvo que IDA y la mayoría de los proveedores no incorporaban las aclaraciones y extensiones SMTP más recientes. Esa es su valoración retrospectiva de 1994, no un censo independiente de cada proveedor o instalación.

La diferencia es importante. Una norma puede publicarse mientras el software que se ejecuta conserva supuestos anteriores. Si la implementación es privada, está fragmentada o resulta difícil de obtener, el operador puede carecer de una vía práctica entre el documento y una versión de reemplazo que pueda probar. Una versión pública ayuda a reducir la distancia porque hace visibles los cambios y sus límites. No puede obligar a un proveedor a distribuirlos, a un administrador a instalarlos ni a un sistema remoto a aceptarlos.

La versión 8 dejó el límite a la vista

Allman utiliza Sendmail 8.6.6 para mostrar que la compatibilidad no es una condición de todo o nada. Describe ESMTP básico conforme al RFC 1425, la extensión de tamaño de mensaje del RFC 1427 y una compatibilidad limitada con el parámetro BODY del RFC 1426. También señala que esta versión no anunciaba 8BITMIME y no convertía correctamente un mensaje para un par SMTP que no admitía datos de ocho bits.

Esos detalles son más precisos que decir que «Sendmail 8 admitía las nuevas normas SMTP». Vinculan capacidades con una versión concreta. El RFC 1425 define el intercambio de capacidades ESMTP mediante EHLO; el RFC 1427 define SIZE; y el RFC 1426 describe la extensión BODY asociada más tarde a 8BITMIME. Lo que anuncia el par, lo que elige el emisor y lo que hace el receptor afectan a la transferencia. El artículo no establece cuándo actualizaron las instalaciones ni con qué frecuencia se daban estos casos en producción.

Otra página oficial sobre los cambios de Sendmail Version 8 califica el software como «condicionalmente conforme» con el RFC 1123 y enumera tanto los requisitos cumplidos como las salvedades pendientes. Esa página cita números posteriores para las extensiones que los mencionados en el artículo de 1994. No conviene fundir ambos documentos en una sola lista de capacidades. En conjunto muestran que cualquier afirmación de conformidad necesita especificar versión, norma y excepciones.

Por tanto, la aportación de Allman no fue simplemente publicar un número de versión mayor. Su artículo hizo legible el límite de la implementación: qué extensión existía, cuál era parcial y dónde seguía fallando la conversión. El salto a la versión 8 tuvo una explicación prosaica: los archivos de la distribución 4.4BSD ya llevaban el número 8.1. No significaba que se hubieran resuelto todos los problemas de protocolo.

El código público dio a los operadores algo comprobable

La Nota 65 de Heng Lu ofrece una lente editorial útil: una norma publicada y el código que se ejecuta responden preguntas distintas. La nota no es evidencia sobre las motivaciones de Allman ni sobre la historia de Sendmail. Aplicada aquí, la distinción es práctica. Una norma dice qué deberían poder hacer los sistemas; una versión fuente permite inspeccionar una implementación; una prueba y un intercambio real muestran lo que hizo una pareja concreta de sistemas.

El código público también distribuye el trabajo. Los mantenedores pueden publicar un cambio común, los proveedores pueden trasladar parches y los operadores pueden comparar su comportamiento local con las fuentes disponibles. Pero las diferencias de configuración, los parches privados y los paquetes antiguos pueden perpetuar la divergencia después de una publicación. Hacer público el código abre la posibilidad de inspección y reparación; no elimina el coste del mantenimiento.

La conclusión debe ser acotada. En el relato de Allman, la pausa de Sendmail amplió la distancia entre las normas SMTP en evolución y las implementaciones disponibles para muchos usuarios. La versión 8 proporcionó un punto público de comparación e incorporó algunas extensiones nuevas, pero el ejemplo de 8.6.6 mantenía límites explícitos. Ni una norma ni una publicación demuestran un despliegue universal. La pregunta útil es si el operador puede identificar la versión exacta, probar su conducta y elegir una vía de soporte cuando la implementación no alcanza el resultado esperado.

Fuentes