Mozilla Thunderbird incorporará soporte nativo para Exchange
(blog.thunderbird.net)- Thunderbird planea ofrecer soporte nativo para Microsoft Exchange, ampliamente usado en empresas e instituciones educativas, a partir de la versión ESR de julio de 2024, y el alcance inicial estará limitado al correo electrónico
- Este trabajo, más allá de añadir soporte para Exchange Web Services (EWS), sirve como impulso para ir ordenando de forma gradual las limitaciones de una arquitectura de protocolos de correo con más de 20 años y código C++ antiguo
- Se eligió Rust como lenguaje de implementación por razones como seguridad de memoria, rendimiento nativo, modularidad y la CI compartida con Firefox, además de la interoperabilidad con XPCOM
- Durante la integración de EWS se crearon crates como
xpcom_async,moz_http,xml_structyews, que envuelven de forma amigable para Rust las llamadas HTTP basadas en XPCOM y la serialización XML - Aunque EWS dejará de estar disponible en Exchange Online después de octubre de 2026, sigue siendo un soporte necesario para Thunderbird debido a la gran cantidad de usuarios de Exchange Server on-premises
Alcance del soporte de Exchange en la ESR de julio de 2024
- Thunderbird planea ofrecer soporte nativo para Exchange en la próxima versión ESR (Extended Support Release) de julio de 2024
- El alcance inicial se limita al correo electrónico
- El soporte para calendario y libreta de direcciones se añadirá más adelante
- Hasta hace poco, las funciones de Exchange solo podían usarse mediante complementos
- La implementación apunta a la API Exchange Web Services (EWS) de Microsoft
- EWS funciona sobre HTTP
- Los cuerpos de solicitud y respuesta usan XML
La carga de una arquitectura de correo de más de 20 años
- La arquitectura actual de protocolos de correo de Thunderbird se basa en código más antiguo que el propio Thunderbird
- Fue desarrollada hace más de 20 años como parte de Netscape Communicator
- Después de que Mozilla transfiriera la propiedad de Thunderbird a la comunidad en 2012, no hubo mantenimiento remunerado hasta su reincorporación a Mozilla Foundation en 2017
- Como se fueron acumulando cambios temporales sin una dirección arquitectónica clara, aún queda mucho código C++ que no usa estándares modernos
- En los 20 años del proyecto Thunderbird nunca se había añadido soporte para un nuevo protocolo de correo
- Mientras los protocolos de correo cambiaban para adaptarse a patrones de uso modernos, la estructura relacionada no pudo actualizarse
- También se ha perdido mucho conocimiento institucional
- El soporte para Exchange es el primer trabajo impulsado por la organización para entender las limitaciones de la arquitectura de Thunderbird y resolverlas gradualmente
Por qué se eligió Rust
- Rust fue elegido como lenguaje para implementar el nuevo soporte de protocolo en Thunderbird
- En esta decisión influyeron tanto ventajas generales de Rust como condiciones específicas de Thunderbird
- Seguridad de memoria: Thunderbird recibe entradas de cualquiera que envíe correos, por lo que reducir bugs de seguridad es importante
- Rendimiento: Rust se ejecuta como código nativo
- Modularidad y ecosistema: se puede aprovechar la estructura modular de Rust y su ecosistema relacionado con email
- Thunderbird está construido sobre código de Firefox, por lo que ya existían condiciones favorables para adoptar Rust
- La infraestructura de CI compartida con Firefox ya soporta Rust
- La capa de interoperabilidad de XPCOM (Cross-Platform Component Object Model) de Firefox permite llamadas entre Rust, C++ y JavaScript
- Los tipos y herramientas de Rust ayudan a crear APIs difíciles de usar incorrectamente
- Permiten evitar referencias circulares o crear funciones que no puedan llamarse con valores sin sentido
- Sus herramientas de documentación vienen incluidas en el lenguaje, lo que resulta útil para un equipo pequeño
- Al crear crates modulares, también pueden reutilizarse en otros proyectos como Thunderbird for Android/K-9 Mail
Restricciones del sistema de build y de XPCOM
- Al ejecutar el primer componente en Rust dentro de Thunderbird, el sistema de build fue el primer obstáculo
- Thunderbird no está estructurado como una dependencia común del código de Firefox
- Durante el build se trae el código de Firefox
- El código de Thunderbird se incorpora como un subárbol de Firefox
- Los archivos de configuración del build apuntan a ese subárbol
- Firefox reúne crates individuales en un solo workspace de Cargo para construir el grafo completo de dependencias de Cargo de todo el árbol
- Thunderbird también necesitaba su propio workspace de Cargo, pero Cargo no permite workspaces anidados
- Como solución, se definió un workspace propio para Thunderbird y se configuró la herramienta de build superior
machpara que construyera este en lugar del workspace de Firefox - Un nuevo subcomando de
machsincroniza dependencias y lockfile con el superior, y luego hace vendoring del superset resultante
- XPCOM fue diseñado con enfoque en C++, por lo que la experiencia de desarrollo en Rust no es fluida
- Implementar y usar interfaces XPCOM requiere mucho boilerplate
- Es difícil aprovechar bien herramientas como
rust-analyzer - Firefox ha reducido mucho su dependencia de XPCOM, pero Thunderbird no pudo hacer una limpieza similar durante su periodo sin mantenimiento
- El nuevo soporte de protocolo de correo requiere implementar cientos de funciones definidas en XPCOM
- Las implementaciones de protocolos existentes reducen la carga heredando clases C++ que ofrecen comportamiento compartido
- En Rust esto no puede hacerse directamente, por lo que la lógica específica del protocolo se implementa en Rust
- Una clase puente en C++ conecta el crate interno
ews_xpcomcon el código compartido existente
- La forma de crear componentes en Rust dentro de Thunderbird está documentada en la documentación
Manejo más idiomático de solicitudes HTTP en Rust
- Firefox ya cuenta con una pila HTTP mediante el componente de red
necko neckoestá escrito en C++ y expuesto vía XPCOM, por lo que usarlo directamente desde Rust requiere mucho boilerplate- Incluso una solicitud GET simple necesita crear muchos objetos XPCOM
- XPCOM gestiona la vida útil de los punteros, pero el compilador de Rust no lo sabe, así que hacen falta bloques
unsafe - Las interfaces necesarias están basadas en callbacks
- El crate interno
xpcom_asyncconvierte tareas asíncronas de XPCOM a la sintaxis async/await de Rust- Almacena en búfer los datos recibidos por callback
- Implementa el trait
Futurede Rust para que quien llama pueda usarawait - El
Futurede Rust es similar aPromisede JavaScript o a las corrutinas de Python
- El crate interno
moz_httpofrece un cliente HTTP inspirado enreqwest- Se encarga de crear los objetos XPCOM necesarios
- Ofrece manejo de errores más idiomático de Rust que el tratamiento estándar de errores de XPCOM
Serialización XML de EWS y nuevos crates
- La tarea más complicada de EWS es convertir entre las estructuras de datos internas de Thunderbird y el XML que EWS requiere o entrega
- Los crates existentes de serialización y deserialización XML no cumplían con los requisitos
- El modelo de datos de
serdeno encaja bien con XML, por lo que es difícil distinguir atributos y elementos - EWS es sensible a los namespaces XML, algo poco familiar dentro del enfoque habitual de
serde - Los crates de XML basados en
serdeexigen anotar explícitamente cómo serializar cada campo - EWS define cientos de tipos y decenas de campos por tipo, así que el boilerplate se vuelve inmanejable
- El modelo de datos de
- Una implementación existente basada en
serdebastaba para deserializar XML a Rust, pero no se encontró una herramienta de serialización satisfactoria - El nuevo crate
xml_structofrece traits que definen el comportamiento de serialización XML y un macro procedural derive- Genera automáticamente implementaciones de traits para estructuras de datos de Rust
- Está construido sobre el crate existente
quick_xml - Busca un mapeo entre XML y Rust con poco boilerplate
- No depende de internals de Thunderbird/Firefox y está en etapa inicial de desarrollo
- El nuevo crate
ewsdefine tipos y APIs de serialización y deserialización XML para operaciones EWS- Está basado en
xml_structyserde - Está en etapa inicial de desarrollo y publicado en GitHub
- Está basado en
Pruebas, manejo de errores y plan de integración con la UI
- Antes de añadir las siguientes funciones importantes, se está reforzando el testing automatizado
- Además de pruebas unitarias, se añadió un servidor EWS simulado para pruebas de integración
- Durante ese refuerzo aparecieron y se corrigieron algunos crashes y problemas de doble sincronización
- Ahora será más fácil probar y validar nuevas funciones
- El manejo de errores de EWS está en proceso de mejora
- El comportamiento de errores de EWS suele estar poco documentado
- Una solicitud completa puede fallar por throttling o por una estructura incorrecta
- Algunas partes de una solicitud pueden tener éxito y otras fallar por IDs inválidos
- Algunos errores pueden manejarse a nivel de protocolo, pero otros pueden requerir intervención del usuario o ser difíciles de resolver
- El soporte del protocolo EWS sigue ampliándose mediante los crates
ewsy el crate internoews_xpcom, mientras se integra con la UI de Thunderbird- Un parche reciente ya permite añadir cuentas EWS a Thunderbird
- Es posible sincronizar la jerarquía de carpetas de la cuenta desde el servidor remoto
- Las carpetas sincronizadas pueden mostrarse en la UI
- Por ahora, esta función en estado alfa está oculta detrás de un build flag y valores de configuración
- El siguiente trabajo será traer la lista de mensajes desde el servidor remoto y generalizar el soporte de correo saliente de Thunderbird
- Con fines de mantenimiento, también se está documentando cómo encajan los distintos componentes, la arquitectura existente de protocolos de correo en Thunderbird y la dirección de futuras mejoras
Relación entre EWS y Microsoft Graph
- EWS ya no podrá usarse en Exchange Online después de octubre de 2026
- La investigación previa del proyecto mostró que aún hay una cantidad considerable de usuarios que siguen usando Exchange Server on-premises
- Muchas empresas e instituciones educativas ejecutan Exchange Server en su propio hardware
- Estas instalaciones on-premises generalmente soportan EWS
- No pueden soportar la API Graph basada en Azure
- El soporte para EWS será, en el futuro cercano, una forma de atender a estos usuarios
- La API Graph todavía tiene algunos problemas sin resolver
- La API Graph fue diseñada pensando en servicios web, no en aplicaciones de escritorio
- Añadir primero el soporte para EWS da tiempo para encontrar soluciones a esos problemas antes de crear soporte para la API Graph
- El trabajo con Rust y EWS forma parte de un esfuerzo más amplio para reducir los tiempos de respuesta de Thunderbird y aumentar la resiliencia del núcleo del software
1 comentarios
Opiniones de Hacker News
No entiendo por qué lo implementan si EWS ya está programado para ser retirado y lo van a eliminar en dos años: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...
Si EWS desaparece, también se irán bastantes clientes, aunque al principio quizá no lo suficiente como para afectar los resultados de Microsoft.
Luego, eventualmente, quedará claro que todos los correos electrónicos son equivalentes, y Exchange Online podría terminar como una nota al pie en la historia. En apariencia es algo vergonzoso, como si Microsoft hubiera fracasado estrepitosamente con el correo electrónico, pero en realidad no necesariamente es así.
Operar un sistema de correo electrónico es doloroso, y lo que Microsoft realmente quiere son los datos y metadatos que puede extraer y vender a otros obsesionados con los datos. El correo electrónico, en términos de almacenamiento, suele ser estático y grande, pero los intercambios entre personas pueden ser una mina de oro.
Lo ideal sería hacer que AWS, Google y otros carguen con el dolor, y lograr que los clientes usen Outlook. Después, cambiar Outlook para que almacene las credenciales en la nube de Microsoft, como en la nueva versión Electron de Outlook, y usar esas credenciales para extraer datos de correo electrónico alojados en las nubes de otros, mientras ellos pagan los costos de almacenamiento. Excelente.
La Graph API también fue evaluada y podría volver a evaluarse en el futuro, pero hoy tiene una cobertura de soporte más limitada que EWS y carece de algunas funciones necesarias para una aplicación de escritorio.
Aunque se haya anunciado que el soporte de EWS será eliminado en Exchange Online, sigue teniendo valor a corto plazo para permitir el acceso a una base amplia de usuarios y, a largo plazo, para dar soporte a usuarios de instalaciones on-premise.
Si el objetivo es simplemente aumentar la cantidad de usuarios de Thunderbird, estratégicamente tiene sentido, pero ideológicamente se ve mucho mejor el soporte para JMAP.
Hace poco probé Thunderbird en lugar de Outlook, y tenía el mismo problema que Firefox antes de la actualización Quantum. Es demasiado lento.
Al cambiar entre carpetas con cientos o miles de correos se nota un retraso, mientras que en Outlook el cambio es prácticamente instantáneo.
Con el calendario es justo al revés, así que por ahora ejecuto ambos en paralelo. Un problema parece ser el puente iCal hacia el servidor de Outlook que tengo que usar en la empresa.
Lamentablemente, este anuncio no cambia esa parte. Durante un tiempo usé el add-on de EWS que mantenía Ericsson: https://github.com/Ericsson/exchangecalendar
Pero parece que Mozilla rompió interfaces con demasiada rapidez y terminó alejando a muchos desarrolladores de plugins. Ahora están volviendo a poner algunas funciones en el núcleo, y no estoy seguro de que sea una buena estrategia. Creo que sería mejor enfocarse en interfaces estables.
Detesto Exchange, pero me alegra este trabajo. Ahora, incluso estando atrapado en Windows, quizá pueda enviar correctamente correo en texto plano desde Exchange.
Después de ver lo común que es que los correos en texto plano se rendericen con fuentes monoespaciadas en lugar de una forma más razonable, me cuesta justificar el texto plano solo porque “el email HTML es una abominación”.
Decir que “nadie había agregado soporte para un nuevo protocolo de correo en los 20 años de historia del proyecto Thunderbird” es técnicamente correcto, pero cada gran empresa necesitó configuraciones especiales por cliente de correo, es decir, atajos, para implementar autenticación OAuth2 fuera de banda, y Thunderbird también ha acumulado bastantes de esas cosas.
Esos no son protocolos de correo normales. No son IMAP, POP3 ni SMTP; funcionan sobre HTTPS.
Que “nunca se haya agregado un nuevo protocolo de correo” es algo bueno, y este cambio no lo es. El soporte para configuraciones propietarias es práctico y comprensible, pero no es algo bueno.
Solo mitiga por un momento el problema de que el correo electrónico se fragmente en decenas de variantes por empresa, y a largo plazo termina alentando a la gente a aceptar esas variantes.
En cambio, poder usar Thunderbird como cliente es una ganancia neta y una opción práctica.
No entiendo por qué cambiaron el título. Este artículo trata sobre programación en Rust
“Bringing Exchange Support to Thunderbird” parece un artículo sobre Thunderbird y soporte para Exchange, pero eso no es algo que se desprenda de este artículo
Aunque admitir especificaciones propietarias sería útil, me gustaría que Mozilla priorizara la implementación de estándares como el autodescubrimiento de servidores de envío de correo (SMTP). Por ejemplo, el rfc6186 salió en 2011
Hoy los usuarios tienen que ingresar manualmente el nombre de host y el puerto del servidor SMTP; quizá eso esté bien para la gente de este sitio, pero no es nada amigable para el 99.9% restante de la humanidad
El esfuerzo necesario para implementar todo Exchange probablemente sea varios órdenes de magnitud mayor que el descubrimiento del servidor de envío mediante DNS/SRV. De verdad no entiendo las prioridades de Mozilla
¿Esos se manejan como casos especiales?
Vaya, esto me recuerda a cuando trabajaba en IT hace unos 20 años. Era un entorno casi totalmente Microsoft y solo unos pocos usábamos Linux
Exchange siempre fue una de esas cosas para las que era difícil encontrar un buen cliente, y si esto hubiera existido entonces, habría estado saltando de alegría
Usar productos de Microsoft en Linux es un verdadero dolor, y en especial parece que están en proceso de descontinuar la versión web de Teams si no usas Edge :(
Lo de que “alrededor de 2012 Mozilla se desentendió de Thunderbird y transfirió la propiedad a la comunidad, y no hubo mantenimiento pagado hasta que Thunderbird volvió a integrarse a Mozilla Foundation en 2017” fue realmente un escándalo
Es un ejemplo emblemático de las prioridades invertidas de Mozilla
Puede no gustarte, y yo tampoco estoy precisamente encantado. Pero es un hecho, y no valía la pena que Mozilla lo financiara
Ojalá incluyeran de forma nativa la importación de archivos PST para que quienes quieran alejarse de una instalación de Outlook puedan hacer una transición fluida sin tener que tocar Outlook en sí
Ya existen proyectos libres para leer archivos PST, así que solo habría que integrarlos en el producto
Edición: ah, no. Es solo para instalaciones on-premises. Esto es realmente estúpido