Mozilla Thunderbird, Exchange 지원 네이티브 도입

 (blog.thunderbird.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 기업·교육기관에서 널리 쓰이는 Microsoft Exchange를 Thunderbird가 2024년 7월 ESR부터 네이티브로 지원할 예정이며, 첫 범위는 이메일로 제한됨
  • 이번 작업은 Exchange Web Services(EWS) 지원을 넘어, 20년 넘게 이어진 메일 프로토콜 아키텍처와 오래된 C++ 코드의 한계를 점진적으로 정리하는 계기가 됨
  • 구현 언어로는 Rust가 선택됐으며, 메모리 안전성·네이티브 성능·모듈성·Firefox와 공유하는 CI 및 XPCOM 상호운용성이 주요 이유임
  • EWS 통합 과정에서 xpcom_async, moz_http, xml_struct, ews 같은 크레이트가 만들어졌고, XPCOM 기반 HTTP 호출과 XML 직렬화를 Rust 친화적으로 감싸고 있음
  • EWS는 Exchange Online에서 2026년 10월 이후 사용 불가하지만, 온프레미스 Exchange Server 사용자가 많아 Thunderbird에는 여전히 필요한 지원임

2024년 7월 ESR의 Exchange 지원 범위

  • Thunderbird는 다음 ESR(Extended Support) 릴리스인 2024년 7월에 Exchange 지원을 네이티브로 제공할 예정임
  • 초기 범위는 이메일에 한정됨
    • 캘린더와 주소록 지원은 이후 추가될 예정임
    • 최근까지 Exchange 기능은 애드온을 통해서만 사용할 수 있었음
  • 구현 대상은 Microsoft의 Exchange Web Services(EWS) API임
    • EWS는 HTTP 위에서 동작함
    • 요청과 응답 본문은 XML을 사용함

20년 넘은 메일 아키텍처의 부담

  • Thunderbird의 현재 메일 프로토콜 아키텍처는 Thunderbird보다 오래된 코드에 기반함
    • 20년 이상 전 Netscape Communicator의 일부로 개발됨
    • 2012년 Mozilla가 Thunderbird 소유권을 커뮤니티로 넘긴 뒤, 2017년 Mozilla Foundation에 다시 합류하기 전까지 유급 유지보수가 없었음
  • 큰 아키텍처 방향 없이 임시 변경이 누적되면서, 최신 표준을 쓰지 않는 C++ 코드가 많이 남아 있음
  • Thunderbird 프로젝트 20년 동안 새 메일 프로토콜 지원이 추가된 적이 없었음
    • 메일 프로토콜이 현대적 사용 패턴에 맞춰 변하는 동안 관련 구조는 갱신되지 못함
    • 많은 제도적 지식도 사라진 상태임
  • Exchange 지원은 Thunderbird 아키텍처의 한계를 이해하고 점진적으로 해결하려는 첫 조직 주도 작업임

Rust를 선택한 이유

  • Rust는 Thunderbird의 새 프로토콜 지원 구현 언어로 선택됨
  • 선택 배경에는 일반적인 Rust 장점과 Thunderbird 특유의 조건이 함께 있음
    • 메모리 안전성: Thunderbird는 이메일을 보내는 누구에게서나 입력을 받기 때문에 보안 버그를 줄이는 일이 중요함
    • 성능: Rust는 네이티브 코드로 실행됨
    • 모듈성과 생태계: Rust의 모듈 구조와 이메일 관련 생태계를 활용할 수 있음
  • Thunderbird는 Firefox 코드 위에 만들어져 있어 Rust 도입 여건이 이미 갖춰져 있음
    • Firefox와 공유하는 CI 인프라가 Rust를 지원함
    • Firefox의 XPCOM(Cross-Platform Component Object Model) 상호운용 계층을 통해 Rust, C++, JavaScript 간 호출이 가능함
  • Rust의 타입과 도구는 잘못 쓰기 어려운 API를 만드는 데 도움이 됨
    • 순환 참조를 피하거나, 의미 없는 값으로 호출할 수 없는 함수를 만들 수 있음
    • 문서화 도구가 언어에 기본 포함돼 있어 작은 팀에 유용함
  • 모듈형 크레이트로 만들면 Thunderbird for Android/K-9 Mail 같은 다른 프로젝트에서도 재사용 가능함

빌드 시스템과 XPCOM 제약

  • Thunderbird 안에서 첫 Rust 컴포넌트를 실행할 때 빌드 시스템이 첫 장애물이 됨
  • Thunderbird는 Firefox 코드의 일반적인 의존성처럼 붙는 구조가 아님
    • 빌드 시 Firefox 코드를 가져옴
    • Thunderbird 코드를 Firefox의 서브트리로 가져옴
    • 빌드 설정 파일로 해당 서브트리를 가리킴
  • Firefox는 트리 전체 Cargo 의존성 그래프를 만들기 위해 개별 크레이트를 하나의 Cargo 워크스페이스로 모음
    • Thunderbird도 자체 Cargo 워크스페이스가 필요했지만 Cargo는 중첩 워크스페이스를 허용하지 않음
    • 해결책으로 Thunderbird 자체 워크스페이스를 정의하고, 상위 빌드 도구 mach가 Firefox 워크스페이스 대신 이를 빌드하도록 설정함
    • 새 mach 하위 명령으로 의존성과 lockfile을 상위와 동기화하고, 결과 superset을 vendoring함
  • XPCOM은 C++ 중심으로 설계돼 Rust 개발 경험이 매끄럽지 않음
    • XPCOM 인터페이스 구현과 사용에는 많은 보일러플레이트가 필요함
    • rust-analyzer 같은 도구를 충분히 활용하기 어려움
    • Firefox는 XPCOM 의존을 많이 줄였지만, Thunderbird는 유지보수 공백 동안 유사한 정리 작업을 하지 못했음
  • 새 메일 프로토콜 지원에는 XPCOM에 정의된 수백 개 함수 구현이 필요함
    • 기존 프로토콜 구현은 공유 동작을 제공하는 C++ 클래스를 상속해 부담을 줄임
    • Rust에서는 이를 직접 할 수 없어 프로토콜별 로직을 Rust에 구현함
    • C++ 브리지 클래스가 내부 크레이트 ews_xpcom과 기존 공유 동작 코드를 연결함
  • Thunderbird에서 Rust 컴포넌트를 만드는 방법은 문서에 정리돼 있음

HTTP 요청을 Rust답게 다루기

  • Firefox에는 necko 네트워킹 컴포넌트를 통한 HTTP 스택이 이미 있음
  • necko는 C++로 작성되고 XPCOM으로 노출돼 Rust에서 직접 쓰기에는 보일러플레이트가 많음
    • 단순 GET 요청에도 많은 XPCOM 객체 생성이 필요함
    • XPCOM이 포인터 수명을 관리하지만 Rust 컴파일러는 이를 알지 못해 unsafe 블록이 필요함
    • 필요한 인터페이스는 콜백 기반임
  • Thunderbird 내부 크레이트 xpcom_async는 XPCOM 비동기 작업을 Rust의 async/await 문법으로 변환함
    • 콜백으로 들어오는 데이터를 버퍼링함
    • Rust의 Future trait을 구현해 호출자가 await할 수 있게 함
    • Rust의 Future는 JavaScript의 Promise나 Python 코루틴과 유사함
  • 내부 크레이트 moz_http는 reqwest에서 영감을 받은 HTTP 클라이언트를 제공함
    • 필요한 XPCOM 객체 생성을 처리함
    • 표준 XPCOM 오류 처리보다 Rust다운 오류 처리를 제공함

EWS XML 직렬화와 새 크레이트

  • EWS에서 가장 까다로운 작업은 Thunderbird 내부 데이터 구조와 EWS가 요구하거나 제공하는 XML 사이를 변환하는 일임
  • 기존 XML 직렬화·역직렬화 크레이트는 요구를 충족하지 못함
    • serde의 데이터 모델은 XML과 잘 맞지 않아 속성과 요소를 구분하기 어려움
    • EWS는 XML 네임스페이스에 민감하지만 이는 serde에 익숙한 개념이 아님
    • XML용 serde 계열 크레이트들은 모든 필드의 직렬화 방식을 명시적으로 주석 처리해야 함
    • EWS는 수백 개 타입과 타입별 수십 개 필드를 정의하므로 보일러플레이트가 감당하기 어려움
  • 기존 serde 기반 구현은 XML을 Rust로 역직렬화하는 데는 충분했지만, 만족스러운 직렬화 도구는 찾지 못함
  • 새 크레이트 xml_struct는 XML 직렬화 동작을 정의하는 trait과 절차적 derive 매크로를 제공함
    • Rust 데이터 구조에 대한 trait 구현을 자동 생성함
    • 기존 quick_xml 크레이트 위에 만들어짐
    • XML과 Rust 사이의 보일러플레이트가 적은 매핑을 목표로 함
    • Thunderbird/Firefox 내부에 의존하지 않으며 초기 개발 단계임
  • 새 크레이트 ews는 EWS 작업용 타입과 XML 직렬화·역직렬화 API를 정의함
    • xml_struct와 serde를 기반으로 함
    • 초기 개발 단계이며 GitHub에 공개돼 있음

테스트, 오류 처리, UI 연결 계획

  • 다음 주요 기능을 넣기 전에 자동화 테스트를 보강하는 중임
    • 단위 테스트뿐 아니라 통합 테스트용 mock EWS 서버가 추가됨
    • 테스트 강화 과정에서 몇 가지 크래시와 double-sync 문제가 드러났고 수정됨
    • 새 기능을 더 쉽게 테스트하고 검증할 수 있게 됨
  • EWS 오류 처리는 개선 중임
    • EWS의 오류 동작은 문서화가 부족한 경우가 많음
    • 요청 전체가 throttling이나 잘못된 구조 때문에 실패할 수 있음
    • 요청 일부는 성공하고 일부는 잘못된 ID 때문에 실패할 수 있음
    • 일부 오류는 프로토콜 수준에서 처리 가능하지만, 일부는 사용자 개입이 필요하거나 해결이 어려울 수 있음
  • EWS 프로토콜 지원은 ews와 내부 ews_xpcom 크레이트를 통해 확장되고 있으며 Thunderbird UI와 연결 중임
    • 최근 패치로 EWS 계정을 Thunderbird에 추가할 수 있게 됨
    • 원격 서버에서 계정의 폴더 계층을 동기화할 수 있음
    • 동기화된 폴더를 UI에 표시할 수 있음
    • 현재 이 알파 상태 기능은 빌드 플래그와 설정값 뒤에 숨겨져 있음
  • 다음 작업은 원격 서버에서 메시지 목록을 가져오는 기능과 Thunderbird의 발신 메일 지원 일반화임
  • 유지보수를 위해 각 구성 요소가 어떻게 결합되는지, 기존 Thunderbird 메일 프로토콜 아키텍처와 향후 개선 방향을 문서화하고 있음

EWS와 Microsoft Graph의 관계

  • EWS는 Exchange Online에서 2026년 10월 이후 사용할 수 없음
  • 프로젝트 사전 조사에서는 온프레미스 Exchange Server를 계속 사용하는 사용자가 상당수 있는 것으로 나타남
    • 많은 기업과 교육기관이 자체 하드웨어에서 Exchange Server를 운영함
    • 이런 온프레미스 설치는 대체로 EWS를 지원함
    • Azure 기반 Graph API는 지원할 수 없음
  • EWS 지원은 가까운 미래에 이런 사용자를 지원하는 수단이 됨
  • Graph API에는 아직 해결되지 않은 문제가 일부 있음
    • Graph API는 데스크톱 애플리케이션이 아니라 웹 기반 서비스를 염두에 두고 만들어짐
    • EWS 지원을 먼저 추가하면 Graph API 지원을 만들기 전에 해당 문제의 해법을 찾을 시간을 확보할 수 있음
  • Rust와 EWS 작업은 Thunderbird의 턴어라운드를 줄이고 소프트웨어 핵심부의 회복력을 높이려는 더 큰 노력의 일부임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이미 EWS가 폐기 예정이고 2년 뒤 제거된다는데 왜 구현하는지 모르겠음: https://techcommunity.microsoft.com/t5/exchange-team-blog/re...

    • EWS는 Outlook이 아닌 클라이언트가 동작할 수 있는 유일하게 현실적인 방법이고, MAPI는 딱히 열린 API가 아님
      EWS가 사라지면 고객도 꽤 많이 떠날 것이고, 처음에는 Microsoft의 실적에 타격을 줄 정도는 아닐 수 있음
      그러다 결국 모든 이메일은 동등하다는 점이 드러나고, Exchange Online은 역사 속 각주가 될 수 있음. Microsoft가 이메일을 하다가 크게 망친 셈이라 겉보기엔 좀 민망하지만, 실제로는 꼭 그렇지만도 않음
      이메일 시스템 운영은 고통스럽고, Microsoft가 진짜 원하는 건 캐내서 다른 데이터 집착자들에게 팔 수 있는 데이터와 메타데이터일 뿐임. 이메일은 저장공간 기준으로 대체로 정적이고 크지만, 개인 간 교환에서 금광이 나올 수 있음
      이상적으로는 AWS, Google 같은 곳이 고통을 떠안게 하고, 고객은 Outlook을 쓰게 만들면 됨. 그러고 나서 새 Electron 버전 Outlook처럼 자격 증명을 Microsoft 클라우드에 저장하게 바꾸고, 그 자격 증명으로 다른 사람들의 클라우드에 있는 이메일 데이터를 캐내면 저장 비용은 그쪽이 부담함. 아주 훌륭함
    • Sean Burke가 관련 Bugzilla 버그에서 말했듯이 현재 EWS가 Exchange Online과 온프레미스 설치 모두를 지원하는 최선의 방법임: https://bugzilla.mozilla.org/show_bug.cgi?id=1847846#c2
      Graph API도 검토됐고 앞으로 다시 검토될 수 있지만, 현재는 EWS보다 지원 범위가 좁고 데스크톱 애플리케이션에 필요한 기능 일부가 부족함
      Exchange Online에서 EWS 지원이 제거된다는 발표가 있었어도, 단기적으로는 넓은 사용자층의 접근을 가능하게 하고 장기적으로는 온프레미스 설치 사용자를 지원하는 데 여전히 가치가 있음
    • Exchange 같은 걸 상대할 때는 당분간 현실적인 다른 선택지가 거의 없기 때문임
    • 모두가 Exchange Online을 쓰는 건 아님

  • 목표가 단순히 Thunderbird 사용자를 늘리는 것이라면 전략적으로는 말이 되지만, 이념적으로는 JMAP 지원이 훨씬 더 좋아 보임

    • 이번에 해낸 작업 대부분은 앞으로 JMAP 지원을 추가하는 데도 핵심이 될 것 같음

  • 최근 Outlook 대신 Thunderbird를 써봤는데, Quantum 업데이트 전 Firefox와 같은 문제가 있었음. 너무 느림
    수백~수천 개 메일이 있는 폴더 사이를 전환할 때 눈에 띄는 지연이 있는데, Outlook에서는 사실상 즉시 전환됨

    • Windows를 쓴다면, 내 경험상 Thunderbird 프로필을 Windows Defender 예외에 추가하기 전까지 Thunderbird는 거의 못 쓸 수준임
    • 내 경험은 완전히 반대임. 메일에 Outlook을 쓰는 건 너무 고통스럽고, 특히 검색이 제대로 안 됨. Thunderbird에서는 expressionsearchNG를 사용함
      일정은 정반대라서 지금은 둘을 나란히 실행하고 있음. 한 가지 문제는 회사에서 써야 하는 Outlook 서버로 가는 iCal 브리지인 것 같음
      이번 발표로는 그 부분이 안타깝게도 바뀌지 않음. 한동안 Ericsson이 유지하던 EWS 애드온을 썼음: https://github.com/Ericsson/exchangecalendar
      하지만 Mozilla가 인터페이스를 빠르게 깨뜨리면서 많은 플러그인 개발자를 떠나게 만든 것 같음. 이제 다시 일부 기능을 코어에 넣고 있는데, 좋은 전략인지 잘 모르겠음. 차라리 안정적인 인터페이스에 집중해야 한다고 봄

  • Exchange는 싫지만 이 작업은 반가움. 이제 Windows에 갇힌 상황에서도 Exchange에서 일반 텍스트 메일을 성공적으로 보낼 수 있을지도 모름

    • 그렇게 하면 기술 순수주의나 옛 시절 향수 때문에 여러 이메일 클라이언트에서 메일이 훨씬 더 안 좋게 보일 수 있음
      일반 텍스트 이메일이 더 합리적인 방식이 아니라 고정폭 글꼴로 렌더링되는 일이 얼마나 흔한지 보고 나서는, “HTML 이메일은 혐오물”이라는 이유만으로 일반 텍스트를 정당화하기 어렵다고 느낌

  • “Thunderbird 프로젝트의 20년 전체 역사에서 새 메일 프로토콜 지원을 추가한 사람이 없었다”는 말은 기술적으로는 맞지만, 대기업마다 OAuth2 대역 외 인증 구현에 이메일 클라이언트별 특수 설정, 즉 우회가 필요했고 Thunderbird도 그런 걸 꽤 많이 모아왔음
    이것들은 일반적인 메일 프로토콜이 아님. IMAP, POP3, SMTP가 아니라 HTTPS 위에서 동작함
    “새 메일 프로토콜을 추가한 적이 없다”는 건 좋은 일이고, 이번 변화는 좋지 않음. 독점 설정 지원은 실용적이고 이해할 수 있지만 좋은 일은 아님
    이메일이 기업별 수십 가지 변형으로 쪼개지는 문제를 잠깐 완화할 뿐이고, 장기적으로는 사람들이 그런 변형을 받아들이도록 부추기게 됨

    • 직원들은 회사 이메일 제공자를 선택할 수 없고, 99.99999%에게 이건 목숨 걸고 싸울 언덕이 아님
      반면 Thunderbird를 클라이언트로 쓸 수 있게 되는 것은 순이익이고 실용적인 선택임
    • 대기업 중 하나가 아니라, 업무용 이메일에서 압도적으로 가장 흔히 쓰이는 Microsoft Exchange, 특히 Exchange Online임

  • 제목이 왜 바뀌었는지 모르겠음. 이 글은 Rust 프로그래밍에 대한 글임
    “Bringing Exchange Support to Thunderbird”는 Thunderbird와 Exchange 지원에 관한 글처럼 보이는데, 그 내용은 이 글에서 알 수 있는 게 아님

    • 글의 첫 문단이 언어보다 Exchange에 초점을 맞추고 있으니, 구현보다 기능 자체가 더 중요해 보임. 대부분의 사용자도 그걸 더 신경 씀
    • 같은 글을 전체 제목으로 앞서 올렸지만 관심을 못 받았음: https://news.ycombinator.com/item?id=40095870
    • 무슨 소리인지 모르겠음. 글의 후반부 전체가 Thunderbird의 Exchange 지원에 관한 내용임

  • 독점 사양 지원이 유용하긴 하겠지만, Mozilla가 이메일 제출 서버(SMTP) 자동 발견 같은 표준 구현을 우선했으면 좋겠음. 예를 들어 rfc6186은 2011년에 나왔음
    현재 사용자는 SMTP 서버의 호스트명과 포트를 직접 입력해야 하는데, 이 사이트에 있는 사람들에게는 괜찮을지 몰라도 나머지 99.9%의 인류에게는 전혀 친절하지 않음
    Exchange 전체를 구현하는 데 필요한 노력은 DNS/SRV를 통한 제출 서버 발견보다 아마 몇 자릿수는 더 클 것임. Mozilla의 우선순위가 정말 이해되지 않음

    • Hotmail, Google, Yahoo 계정을 Thunderbird에 추가할 때는 그런 정보를 입력하지 않았던 것 같음. 그냥 각 이메일 주소만 썼음
      이것들은 특수 사례로 처리되는 건가?

  • 와, 20년쯤 전 IT에서 일하던 때가 생각남. 거의 완전한 Microsoft 환경에서 몇 명만 Linux를 썼음
    Exchange는 항상 괜찮은 클라이언트를 찾기 어려운 것들 중 하나였고, 그때 이게 있었다면 정말 날아갈 듯 기뻤을 것임

    • 지금도 날아갈 듯 기쁨
      Linux에서 Microsoft 제품을 쓰는 건 정말 고통스럽고, 특히 Edge를 쓰지 않으면 Teams 웹 버전을 폐기하는 과정에 들어간 것처럼 보임 :(
    • 우리도 같은 문제가 있었지만 다른 길을 택했음. 회사가 Exchange와 SharePoint를 버리게 만들었고, 그 뒤로 훨씬 행복해졌음

  • “2012년쯤 Mozilla가 Thunderbird에서 손을 떼고 커뮤니티에 소유권을 넘긴 뒤, 2017년 Thunderbird가 Mozilla Foundation에 다시 합류할 때까지 유급 유지보수가 없었다”는 건 정말 스캔들이었음
    Mozilla의 뒤집힌 우선순위를 보여주는 대표 사례임

    • 동의하지 않음. 세상은 웹/모바일 앱 기반 메일로 옮겨갔음
      그게 마음에 안 들 수는 있지만 나도 엄청 기쁜 건 아님. 그래도 사실이고, Mozilla가 자금을 댈 만한 가치가 없었음

  • Outlook 설치에서 벗어나려는 사람들이 Outlook 자체를 만지작거리지 않고도 매끄럽게 전환할 수 있도록 PST 파일 가져오기를 기본 포함해줬으면 함
    PST 파일을 읽는 무료 프로젝트가 이미 있으니 제품군에 통합하기만 하면 됨

답변달기