Mozilla Thunderbird passa a oferecer suporte nativo ao Exchange
(blog.thunderbird.net)- O Thunderbird vai oferecer suporte nativo ao Microsoft Exchange, amplamente usado por empresas e instituições de ensino, a partir do ESR de julho de 2024, com o escopo inicial limitado a e-mail
- Este trabalho vai além do suporte a Exchange Web Services (EWS) e se torna uma oportunidade para reorganizar gradualmente as limitações de mais de 20 anos da arquitetura de protocolos de e-mail e de código C++ antigo
- Rust foi escolhido como linguagem de implementação, principalmente por segurança de memória, desempenho nativo, modularidade e interoperabilidade com o CI compartilhado com o Firefox e com o XPCOM
- Durante a integração com EWS, foram criados crates como
xpcom_async,moz_http,xml_structeews, encapsulando chamadas HTTP baseadas em XPCOM e serialização XML de forma mais amigável para Rust - Embora o EWS não possa mais ser usado no Exchange Online após outubro de 2026, ele continua sendo um suporte necessário no Thunderbird devido ao grande número de usuários de Exchange Server on-premises
Escopo do suporte ao Exchange no ESR de julho de 2024
- O Thunderbird pretende oferecer suporte nativo ao Exchange no próximo lançamento ESR (Extended Support Release), em julho de 2024
- O escopo inicial fica limitado a e-mail
- Suporte a calendário e catálogo de endereços será adicionado depois
- Até recentemente, os recursos de Exchange só podiam ser usados por meio de addons
- O alvo da implementação é a API Exchange Web Services (EWS) da Microsoft
- O EWS funciona sobre HTTP
- Os corpos de requisição e resposta usam XML
O peso de uma arquitetura de e-mail com mais de 20 anos
- A arquitetura atual de protocolos de e-mail do Thunderbird se baseia em código mais antigo que o próprio Thunderbird
- Foi desenvolvida há mais de 20 anos como parte do Netscape Communicator
- Depois que a Mozilla transferiu a propriedade do Thunderbird para a comunidade em 2012, não houve manutenção paga até ele voltar a se juntar à Mozilla Foundation em 2017
- Com mudanças pontuais se acumulando sem uma direção arquitetural maior, ainda restou muito código C++ que não usa padrões modernos
- Em 20 anos de projeto Thunderbird, nunca foi adicionado suporte a um novo protocolo de e-mail
- Enquanto os protocolos de e-mail mudavam para se adequar a padrões modernos de uso, a estrutura relacionada não foi atualizada
- Muito conhecimento institucional também se perdeu nesse processo
- O suporte a Exchange é o primeiro esforço liderado pela organização para entender as limitações da arquitetura do Thunderbird e resolvê-las gradualmente
Por que escolher Rust
- Rust foi escolhido como linguagem de implementação para o novo suporte a protocolo no Thunderbird
- A decisão reúne vantagens gerais do Rust e condições específicas do Thunderbird
- Segurança de memória: como o Thunderbird recebe entrada de qualquer pessoa que envie e-mail, reduzir bugs de segurança é algo importante
- Desempenho: Rust é executado como código nativo
- Modularidade e ecossistema: é possível aproveitar a estrutura modular do Rust e seu ecossistema ligado a e-mail
- Como o Thunderbird é construído sobre código do Firefox, ele já tem condições prontas para adotar Rust
- A infraestrutura de CI compartilhada com o Firefox oferece suporte a Rust
- A camada de interoperabilidade XPCOM (Cross-Platform Component Object Model) do Firefox permite chamadas entre Rust, C++ e JavaScript
- Os tipos e ferramentas do Rust ajudam a criar APIs difíceis de usar de forma incorreta
- É possível evitar referências cíclicas ou criar funções que não podem ser chamadas com valores sem sentido
- Ferramentas de documentação já vêm embutidas na linguagem, o que é útil para equipes pequenas
- Se forem feitos como crates modulares, esses componentes também podem ser reutilizados em outros projetos, como Thunderbird for Android/K-9 Mail
Sistema de build e limitações do XPCOM
- Ao rodar o primeiro componente Rust dentro do Thunderbird, o sistema de build foi o primeiro obstáculo
- O Thunderbird não é estruturado como uma dependência comum do código do Firefox
- Durante o build, ele traz o código do Firefox
- O código do Thunderbird é incluído como uma subtree dentro do Firefox
- Arquivos de configuração de build apontam para essa subtree
- O Firefox reúne crates individuais em um único workspace Cargo para criar o grafo completo de dependências Cargo da árvore inteira
- O Thunderbird também precisava de seu próprio workspace Cargo, mas o Cargo não permite workspaces aninhados
- A solução foi definir um workspace próprio do Thunderbird e configurar a ferramenta de build superior,
mach, para compilá-lo em vez do workspace do Firefox - Um novo subcomando de
machsincroniza dependências e lockfile com o nível superior, fazendo vendoring do superset resultante
- O XPCOM foi projetado com foco em C++, então a experiência de desenvolvimento em Rust não é muito fluida
- Implementar e usar interfaces XPCOM exige muito boilerplate
- É difícil aproveitar bem ferramentas como
rust-analyzer - O Firefox reduziu bastante sua dependência de XPCOM, mas o Thunderbird não conseguiu fazer uma limpeza semelhante durante o período sem manutenção
- O suporte ao novo protocolo de e-mail exige implementar centenas de funções definidas no XPCOM
- Implementações de protocolos existentes reduzem essa carga herdando classes C++ que fornecem comportamento compartilhado
- Em Rust, isso não pode ser feito diretamente, então a lógica específica do protocolo é implementada em Rust
- Uma classe bridge em C++ conecta o crate interno
ews_xpcomao código compartilhado já existente
- A forma de criar componentes Rust no Thunderbird está documentada aqui
Lidando com requisições HTTP de forma idiomática em Rust
- O Firefox já tem uma stack HTTP por meio do componente de rede
necko - O
neckoé escrito em C++ e exposto via XPCOM, o que gera muito boilerplate para uso direto em Rust- Mesmo uma requisição GET simples exige criar muitos objetos XPCOM
- O XPCOM gerencia o tempo de vida dos ponteiros, mas o compilador Rust não sabe disso, então blocos
unsafesão necessários - As interfaces necessárias são baseadas em callbacks
- O crate interno
xpcom_asyncconverte trabalho assíncrono de XPCOM para a sintaxe async/await do Rust- Ele faz buffering dos dados recebidos por callback
- Implementa o trait
Futuredo Rust para que quem chama possa usarawait - O
Futuredo Rust é semelhante aPromisedo JavaScript ou corrotinas do Python
- O crate interno
moz_httpoferece um cliente HTTP inspirado noreqwest- Ele cuida da criação dos objetos XPCOM necessários
- Também fornece um tratamento de erros mais idiomático em Rust do que o padrão do XPCOM
Serialização XML do EWS e novos crates
- A parte mais complicada do EWS é converter entre estruturas de dados internas do Thunderbird e o XML exigido ou retornado pelo EWS
- Crates existentes de serialização e desserialização XML não atenderam aos requisitos
- O modelo de dados do
serdenão se encaixa bem em XML, dificultando distinguir atributos de elementos - O EWS é sensível a namespaces XML, mas isso não é um conceito familiar ao
serde - Crates da família
serdepara XML exigem anotar explicitamente como cada campo deve ser serializado - Como o EWS define centenas de tipos e dezenas de campos por tipo, o boilerplate se torna inviável
- O modelo de dados do
- Uma implementação existente baseada em
serdeera suficiente para desserializar XML em Rust, mas não foi encontrada uma ferramenta de serialização satisfatória - O novo crate
xml_structfornece traits que definem o comportamento de serialização XML e macros derive procedurais- Ele gera automaticamente implementações de trait para estruturas de dados Rust
- É construído sobre o crate
quick_xml - Busca um mapeamento entre XML e Rust com pouco boilerplate
- Não depende internamente de Thunderbird/Firefox e está em estágio inicial de desenvolvimento
- O novo crate
ewsdefine tipos para operações EWS e APIs de serialização e desserialização XML- Ele se baseia em
xml_structeserde - Está em estágio inicial de desenvolvimento e foi publicado no GitHub
- Ele se baseia em
Testes, tratamento de erros e plano de integração com a UI
- Antes de adicionar os próximos recursos principais, o time está reforçando os testes automatizados
- Além de testes unitários, foi adicionado um servidor EWS mock para testes de integração
- Durante o reforço dos testes, alguns crashes e problemas de double-sync foram revelados e corrigidos
- Isso torna mais fácil testar e validar novos recursos
- O tratamento de erros do EWS está sendo melhorado
- O comportamento de erro do EWS muitas vezes é pouco documentado
- Uma requisição inteira pode falhar por throttling ou por estrutura inválida
- Partes de uma requisição podem ter sucesso enquanto outras falham por IDs incorretos
- Alguns erros podem ser tratados no nível do protocolo, enquanto outros podem exigir intervenção do usuário ou ser difíceis de resolver
- O suporte ao protocolo EWS está sendo expandido por meio dos crates
ewse do crate internoews_xpcom, enquanto é conectado à UI do Thunderbird- Patches recentes já permitem adicionar contas EWS ao Thunderbird
- Já é possível sincronizar a hierarquia de pastas da conta a partir do servidor remoto
- As pastas sincronizadas podem ser exibidas na UI
- No momento, esse recurso em estado alfa está escondido atrás de uma flag de build e de valores de configuração
- O próximo trabalho inclui buscar a lista de mensagens no servidor remoto e generalizar o suporte a envio de e-mail no Thunderbird
- Para facilitar a manutenção, também está sendo documentado como cada componente se encaixa, junto da arquitetura atual de protocolos de e-mail do Thunderbird e das direções futuras de melhoria
Relação entre EWS e Microsoft Graph
- O EWS não poderá mais ser usado no Exchange Online após outubro de 2026
- A pesquisa preliminar do projeto indicou que ainda há um número considerável de usuários que continuam usando Exchange Server on-premises
- Muitas empresas e instituições de ensino operam Exchange Server em hardware próprio
- Essas instalações on-premises normalmente oferecem suporte a EWS
- Elas não conseguem oferecer suporte à Graph API baseada em Azure
- O suporte a EWS será, no futuro próximo, uma forma de atender esses usuários
- Ainda existem alguns problemas não resolvidos com a Graph API
- A Graph API foi criada pensando em serviços baseados na web, não em aplicativos desktop
- Adicionar primeiro o suporte a EWS dá tempo para encontrar soluções para esses problemas antes de desenvolver suporte à Graph API
- O trabalho com Rust e EWS faz parte de um esforço maior para reduzir o tempo de resposta do Thunderbird e aumentar a resiliência do núcleo do software
1 comentários
Opiniões no Hacker News
Não entendo por que implementar isso se o EWS já está previsto para ser descontinuado e será removido em dois anos: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...
Quando o EWS desaparecer, muitos clientes também irão embora, e no começo talvez isso não seja suficiente para afetar os resultados da Microsoft
Mas, no fim, vai ficar claro que todos os e-mails são equivalentes, e o Exchange Online pode virar uma nota de rodapé na história. Por fora parece meio constrangedor, como se a Microsoft tivesse estragado feio sua atuação em e-mail, mas na prática não é necessariamente assim
Operar sistemas de e-mail é doloroso, e o que a Microsoft realmente quer são dados e metadados que possa extrair e vender para outros obcecados por dados. E-mail costuma ser estático e grande em termos de armazenamento, mas das trocas entre pessoas pode sair uma mina de ouro
O ideal é deixar lugares como AWS e Google assumirem a dor e fazer os clientes usarem o Outlook. Depois, mudar para que as credenciais sejam armazenadas na nuvem da Microsoft, como no novo Outlook em Electron, e usar essas credenciais para extrair dados de e-mail nas nuvens dos outros, enquanto eles arcam com o custo de armazenamento. Excelente
A Graph API também foi avaliada e pode voltar a ser avaliada no futuro, mas hoje ela tem cobertura de suporte menor que o EWS e carece de alguns recursos necessários para aplicações desktop
Mesmo com o anúncio de que o suporte a EWS será removido do Exchange Online, ele ainda tem valor no curto prazo por permitir acesso a uma base ampla de usuários e, no longo prazo, por dar suporte a usuários de instalações on-premises
Se o objetivo é simplesmente aumentar o número de usuários do Thunderbird, estrategicamente faz sentido, mas ideologicamente o suporte a JMAP parece muito melhor
Recentemente experimentei usar o Thunderbird no lugar do Outlook, e ele tinha o mesmo problema do Firefox antes da atualização Quantum. Lento demais
Ao alternar entre pastas com centenas a milhares de e-mails, há um atraso perceptível, enquanto no Outlook a troca é praticamente instantânea
Para calendário é o contrário, então hoje mantenho os dois rodando lado a lado. Um problema parece ser a ponte iCal para o servidor Outlook que sou obrigado a usar na empresa
Infelizmente, este anúncio não muda essa parte. Por um tempo usei o add-on de EWS mantido pela Ericsson: https://github.com/Ericsson/exchangecalendar
Mas parece que a Mozilla quebrou interfaces rapidamente e afastou muitos desenvolvedores de plugins. Agora está colocando de volta algumas funcionalidades no core, e não sei se isso é uma boa estratégia. Acho que seria melhor focar em interfaces estáveis
Odeio Exchange, mas fico feliz com este trabalho. Agora talvez, mesmo preso ao Windows, eu consiga enviar e-mails em texto simples pelo Exchange com sucesso
Depois de ver como é comum e-mails em texto simples serem renderizados em fonte monoespaçada, em vez de uma forma mais razoável, ficou difícil para mim justificar texto simples apenas com o argumento de que “e-mail em HTML é uma abominação”
Dizer que “em toda a história de 20 anos do projeto Thunderbird ninguém havia adicionado suporte a um novo protocolo de e-mail” é tecnicamente correto, mas cada grande empresa exigiu configurações especiais por cliente de e-mail para suas implementações de autenticação OAuth2 fora de banda, ou seja, gambiarras, e o Thunderbird acumulou bastante disso
Essas coisas não são protocolos de e-mail comuns. Não são IMAP, POP3 ou SMTP; funcionam sobre HTTPS
“Nunca ter adicionado um novo protocolo de e-mail” é algo bom, e esta mudança não é boa. Dar suporte a configurações proprietárias é prático e compreensível, mas não é algo bom
Isso apenas alivia por um tempo o problema de o e-mail se fragmentar em dezenas de variações por empresa e, no longo prazo, acaba incentivando as pessoas a aceitarem essas variações
Por outro lado, poder usar o Thunderbird como cliente é um ganho líquido e uma escolha pragmática
Não entendo por que o título foi alterado. Este texto é sobre programação em Rust
“Bringing Exchange Support to Thunderbird” parece um texto sobre o Thunderbird e suporte ao Exchange, mas o conteúdo disso não é algo que se consiga saber por este texto
Suporte a especificações proprietárias pode até ser útil, mas eu gostaria que a Mozilla priorizasse a implementação de padrões, como descoberta automática de servidores de submissão de e-mail (SMTP). Por exemplo, a RFC 6186 saiu em 2011
Hoje o usuário precisa digitar manualmente o hostname e a porta do servidor SMTP; isso talvez seja ok para as pessoas deste site, mas não é nada amigável para os outros 99,9% da humanidade
O esforço necessário para implementar o Exchange inteiro provavelmente é algumas ordens de grandeza maior do que a descoberta de servidor de submissão via DNS/SRV. Realmente não entendo as prioridades da Mozilla
Esses casos são tratados como casos especiais?
Nossa, isso me lembra quando eu trabalhava em TI uns 20 anos atrás. Era um ambiente quase totalmente Microsoft, com apenas algumas pessoas usando Linux
O Exchange sempre foi uma daquelas coisas para as quais era difícil achar um cliente decente, e se isso existisse naquela época eu teria ficado nas nuvens
Usar produtos Microsoft no Linux é realmente doloroso e, especialmente se você não usa o Edge, parece que estão em processo de desativar a versão web do Teams :(
Foi realmente um escândalo que “por volta de 2012 a Mozilla tenha largado o Thunderbird e transferido a propriedade para a comunidade, ficando sem manutenção paga até 2017, quando o Thunderbird voltou a se juntar à Mozilla Foundation”
É um exemplo emblemático das prioridades invertidas da Mozilla
Você pode não gostar disso, e eu também não fico superfeliz. Mas é um fato, e não valia a pena a Mozilla financiar isso
Eu gostaria que incluíssem por padrão a importação de arquivos PST, para que pessoas tentando se livrar de instalações do Outlook possam migrar sem precisar mexer no próprio Outlook
Já existem projetos gratuitos que leem arquivos PST; bastaria integrá-los à suíte
Edit: ah, não. É só para on-premises. Isso é muito idiota