Resumen

  • La actualización del 25 de septiembre enumera ocho defectos posteriores al cambio que el IETF dio por corregidos, desde remitentes confirmados enviados a moderación hasta correo masivo descartado y fallos de entrega DMARC.
  • El problema de los rebotes descubrió una acumulación antigua. Cuando el nuevo proceso empezó a desactivar suscriptores basándose en rebotes posiblemente erróneos, el IETF lo detuvo y reactivó las direcciones afectadas mientras preparaba una corrección.

Primero llegó el anuncio de éxito. El 11 de septiembre, el IETF comunicó que había terminado la transición a una infraestructura nueva de correo. Describió funciones separadas en contenedores, programación con Kubernetes, nuevo software antispam, mejor manejo de certificados y un tratamiento de rebotes mejorado. Ese día actualizó el título y la introducción para declarar la transición completa; buena parte de los detalles técnicos seguía siendo la información publicada el 28 de agosto.

Eso registra un cambio de sistema. No es un informe operativo.

El informe llegó el 25 de septiembre. Jay Daley, director ejecutivo del IETF, dijo que la mayoría de los problemas ya se había resuelto y describió ocho reparados y dos aún en curso. También explicó que el proyecto se había encargado tres años antes y que, tras sufrir problemas repetidos, se pidió a otro contratista que lo terminara. Un componente central del trabajo anterior no se reescribió y sus problemas no se detectaron antes del lanzamiento. «Fue un error nuestro», escribió Daley.

No fue una caída espectacular. Fueron reglas pequeñas en las uniones entre las listas y quienes realmente envían correo. Una dirección confirmada que publicaba en una lista sin estar suscrita no aparecía en la lista global de remitentes permitidos; el mensaje quedaba en moderación. La cabecera no estándar Precedence: Bulk, una señal usada para identificar correo masivo, se descartaba sin aviso, sobre todo en mensajes de IANA, la autoridad que coordina identificadores únicos de Internet. BATV —validación de etiquetas en direcciones de rebote— se procesaba mal. Direcciones ya confirmadas con letras mayúsculas tenían que confirmar de nuevo. Varias reglas para remitentes inusuales eran inaccesibles. Algunos nombres From de Outlook se dividían en dos partes. Las notificaciones de Postorius usaban una dirección provisional porque el campo de responsable del sitio estaba vacío. La reescritura DMARC también fallaba en ciertas entregas según el número de destinatarios.

El director ejecutivo dijo que esos ocho problemas estaban corregidos. Es un recuento de defectos identificados, no una medida de todos los mensajes fallidos ni de todas las personas afectadas. La actualización no ofrece denominadores.

El problema más delicado estaba en los rebotes. Por limitaciones estructurales de la infraestructura anterior, los rebotes no llegaban a las listas para procesarse. Por eso no se daban de baja direcciones. Se acumuló una lista de direcciones descritas como inalcanzables que seguían suscritas. El nuevo proceso empezó a recorrerla. Entonces los responsables de las listas recibieron numerosos avisos de que se desactivarían suscriptores por exceso de rebotes.

La máquina tenía una cola y emitía un veredicto. Todavía no tenía un veredicto fiable. El IETF dijo que había pruebas de que algunos rebotes eran incorrectos. Su respuesta fue detener el procesamiento y reactivar todas las direcciones que este había desactivado, hasta corregirlo. La decisión favoreció temporalmente conservar una dirección quizá muerta frente a una automatización que podía expulsar a alguien activo. Fue una medida concreta de protección, no prueba de que la acumulación hubiera desaparecido.

La misma actualización registró otra sorpresa de rendimiento: el modo VERP predeterminado de Mailman redujo los tiempos de procesamiento entre cuatro y cinco órdenes de magnitud, según el IETF. VERP se desactivó mientras se investigaba. El anuncio no proporciona tiempo de referencia, carga de trabajo ni demora absoluta. El nuevo filtro Rspamd seguía en ajuste porque estaba dejando pasar demasiado spam.

El orden importa. El anuncio del 11 de septiembre presentaba un mejor procesamiento de rebotes y menos oportunidades de spam como resultados previstos. El informe del 25 de septiembre muestra por qué la intención cuesta poco y la evidencia operativa cuesta mucho: el nuevo proceso expuso una acumulación antigua y señales dudosas; el filtro de spam todavía necesitaba ajustes. Una infraestructura modular no borra la deuda de datos heredada ni vuelve fiables sus primeros veredictos por decreto.

Para cualquier grupo cuyo trabajo dependa de listas compartidas, la diferencia es clara. Una migración completada es un evento con fecha. La entrega fiable es un resultado que debe repetirse a lo largo de la identidad del remitente, la moderación, la expansión de listas, la reescritura, la autenticación, la interpretación del rebote y la recepción final. Cada frontera puede superar su propia prueba y aun así el mensaje puede fallar después.

El informe público deja ver la decisión de control, pero no su coste. No indica cuántas direcciones se reactivaron, qué proporción de rebotes era falsa, cuánto tiempo permaneció detenido el proceso, cuál era la referencia de VERP ni cuándo acabó el ajuste de Rspamd. Esos datos cambiarían la evaluación de la recuperación. La conclusión firme es más acotada: el IETF detuvo las bajas cuando las pruebas de rebote no eran fiables y publicó esa corrección.

Fuentes