Thank you.
Thank you very much.
Welcome everyone to this short story of a not so short project, which is supporting Microsoft
Exchange in Thunderbird.
My name is Brennan Bolivia.
I'm a staff software engineer at MCLA, which is the Mozilla Foundation subsidiary that looks
after Thunderbird hands-in-hand with Thunderbird Community Council.
Part of my day job is looking after Thunderbird for desktop and also involved in maintaining
ISPD, which is the Mozilla ISPD database.
More specifically, in the past couple years, and I've been here recently, I was in charge of leading
the work to implement support for Microsoft Exchange.
I did say the past couple years, because it hasn't been a fairly long project, so let's start
all story at the very beginning.
We went back to 2023 and started by the laying out of the basis what even is Microsoft Exchange.
Exchange is a name for the backend, for some of Microsoft's productivity tools, such as email,
Canada, contacts.
If you've used app look in the past with one of those features, or you are using
Outlook with one of those features in your workplace or anything, you have you are
technically using Exchange.
Exchange can be used with open protocols, such as I map up 3SMTP.
However, it's very often used in corporate environments that are heavily looked down,
and so those protocols might not be available in only proprietary Microsoft APIs can be used.
So there's been a very high demand for a long time for Thunderbird to support those APIs
from users, from within those corporate environments, who don't really have a lot of leverage
with their IT departments, and we want to help those users.
So we started by asking ourselves, how do we talk to an extension server?
There are multiple APIs for that.
There's an active sync, AWS graph, I think there's one or two more.
And we settled on an API called AWS, which stands for Exchange Web Services, which is an XML
of a virtual TPA API.
We picked that one for three main reasons.
One is there is already a fairly well-established open source email client at that
Supported AWS, which is a volition.
Having a volition code that we can use as a reference has been very helpful, because I don't
know if you've ever used or looked at the AWS API documentation.
It's very much more than API reference, meaning that it's going to be very good for describing
data structures, operations structures, and so on.
But not so much for describing behavior.
So for example, if I'm using this data structure in this context, what field is required,
what field is optional, that's not really part of that documentation.
And so having that code base that we can use as a, that we can refer to, very helpful.
A second thing we looked at was the application support, specifically between the AWS and
Graph, which is the kind of newer, shiny thing.
And although Graph does support notifications, it's more heavily based around push notifications,
where we would need a central server or components and transit all the notifications from all of
them in order to, for this to work, and obviously we don't really want to do that.
On the other hand, AWS also supports push notifications, but also supports what sometimes
referred to as pull notifications, where you request a, you send a request from API
endpoints, and you wait until either times out or response with new data.
And that is way, frankly, for, for their applications, like things like Thunderbird.
And the third reason was that AWS provides decent support for both on-premise servers,
and Microsoft 365, which is the Microsoft SaaS platform.
And so that allows us to cover as many users as possible.
I can already hear some people think that, and say, that's, you know,
indeed, Microsoft has announced that, that's AWS on Microsoft 365 is going to be
EOL that the end of the year.
However, when that announcement was made, there was around three years until the,
between then and the deadline, and we essentially bet on our ability to implement
decent support for AWS at least for email, and still have some time to do the same
for graph, and we'll see later on in just a bit, I hope that's better, better, better.
And so now that we had answered the question of which flavor of exchange we want to support,
we had to ask another question, which is how do we even support a new protocol in Thunderbirds?
Because existing protocol support has been around for a while.
I was actually chatting with then earlier this month, who did a bit of archaeology,
and told me that the Pub3I map support initially came back in 93 in let's keep mail 2.0.
And so that's, it's been around for a long time, and so there's really been, in the meantime,
obviously a lot of historical knowledge, there's not a lot of people still around who still remember how that,
what that was like, and also why some decisions were made the way they were.
But also, we don't necessarily want to just copy and paste what was done 30 years ago,
and we decided to also take this as an opportunity to try to define what it means to support a new protocol in Thunderbirds
in a modern way, and we approached this in two ways.
One was introducing interesting breasts for all the more protocol logic, side of things,
for the usual kind of pros, the memory safety guarantees, the reach ecosystem that we can call from.
Also, because Firefox already ships some rescued, and if you don't already know Thunderbird is built on Thunderbird Firefox,
and so although we still had to do some work in order to be able to ship our own rescue,
some of the way was already paid for us there.
And the second kind of problem to that approach was trying to make the new code that we would introduce as reusable as possible.
And that involves both the current infrastructure.
So, you know, the building some compatibility, compatibility layer between, for AC relations,
that come from C++ from into Rust, building some utilities for building some,
e-traumatic HTTP requests in Rust, so on and so forth.
There's a couple more things there.
But we've given a talk about it already, a couple of years ago here at first them.
So if you want to learn more about this, I recommend checking it out.
Also, we also wanted to bring that reusable approach to the more feature-oriented components,
and to, for example, things that don't require, don't require to be protocols specific,
such as storage management, the general message copy logic,
and trying to, as we work through those features, balance, essentially planning for the future,
and taking some time to figure out what needs to be protocol,
or specific, what can be generated, and why still making progress on the future work.
And that feature work actually took longer than we expected from,
we initially expected it to take 6-12 months, then they're taking around a couple years.
And, naturally, for that reason of taking more time to define the approach,
but also for two other reasons.
One was the loss of historical, of historical knowledge.
That's I already mentioned, meaning that for each new feature that we wanted to support,
we had to research obviously how that feature translated through the AWS API,
but also how it already works in Thunderbird for other protocols,
that's needed to be activated, which in phase, which methods need to be implemented,
and that is on, before we can even start implementing support for that feature.
And another reason that, sorry, another reason that took a bit more time was just some expectations we made
towards the start of the project around how things would work in the future,
or where are you working, without having too much detail,
and those expectations some of them didn't survive the test of time,
and we had to cause correct a few times.
But we could then, at least, as part of the way now, and now, as of November,
last year, Thunderbird supports AWS for email.
And so, we're still looking after that implementation, trying to polish it as much as we can,
fixing the remaining bugs.
And, but we've already, we've also already started implementing support for the new
Microsoft Graph API, which seems to be for now something that Microsoft is keeping specific
to Microsoft 365, and so, AWS will still be helpful to support on-premise users.
And this new protocol support is already progressing at a faster pace than AWS,
specifically because we can reuse so much of that code that we introduced for AWS initially.
And so, once we have an email support for email with Graph,
the plan is trying to extend that's reusable base and those implementations as much as possible
with Canada and the rest book, and reuse them and port them to newer and more diverse protocols
in the future, such as Cremat, for example.
And that's it for the story so far.
If you, I believe there's some time for discussion, but if you have more questions,
I'll be outside the room, and you feel pleased to step by the Thunderbird stance as well.
Thank you.
I'm curious, you mentioned exchanges, you know, you've got a lot of the digital consumption,
so I'm curious, how many of you are in that exchange item here?
Yeah, so the question was, I guess, how much of exchanges use is on top of being cooperated
also in the more educational sector, and yeah, there is also a fair amount of that.
The main, I think, I would say the main, the main use of the basis of exchange are cooperated,
but also, yes, schools, universities, and so on, so forth.
Yep.
Is this Thunderbird, or sort of Thunderbird Android?
For now, yes, all right.
So, the question was, is this just for Thunderbird, or Thunderbird for Android as well?
For now, this is just for Thunderbird Desktop, but we also want to view, so you support those features in Thunderbird for Android.
The specific approach that we'll take for Android is not entirely clear how much of the code that we introduced in desktop will be reused for Thunderbird for Android.
But it is part of the plan that we want to support it for Android as well.
Yeah, yeah. I'm, hi, I'm from Booker Monio, we're doing an open source replacement for exchange with AWS, so we have an open source AWS server.
And I can confirm that Thunderbird in version 147 on Fedora for A3, and on Debbie and 13 works, at least with our implementation of AWS.
Does it work? Exactly. It works fully with exchange.
So, the question doesn't work.
The question was, you're the developer of Premiere, that it? Who's, sorry, what's on, I'm an ambassador of Edge, at least I'm.
Well, you work with the Premiere project, which is, which provides among other things, an open source implementation of the exchange API.
And, well, thank you for testing that Thunderbird works with with it. It's kind of on our backlog to to see if that works, but that's good to hear it does.
And, yeah, I mean, we're testing it against actual, actual exchange servers. We have several tests.
Well, we have test accounts on Microsoft 365, and we've also set up test accounts on on-premise servers with with some providers.
And we test all of all. We basically have automated tests, but we also do a bunch of manual testing and QA against those accounts just to verify that it also works in the wide, not just in theory.
So, there's two final questions, please make it quick and possible, so it can switch to.
Yeah, maybe I'm misunderstanding the implementation, but parallel lines are, are any clients to implement this on Microsoft, and they're playing along.
Right there, they're proprietary, you know, I just think it changed them, should we offer them any time?
Yeah, the question was, how reliant are we on Microsoft, because we're using their APIs that they could change or shut down at any point?
I mean, the answer is very reliant, and, fortunately, the kind of reality of the thing is, you know, EWS has been around for since I think Exchange Server 2007.
Graph is also a publicly accessible API. It looks like for now, Microsoft is still planning to make those APIs publicly available.
If they don't, then we'll have to figure out other ways to support the users if we can.
Or stop using Exchange?
Yeah, well, yeah, stop using Exchange. That, I mean, it would be ideal, you know, it would have been ideal if we didn't have to do this project.
But the reality is, if we have to, to be clear between, you know, proprietary platforms and open protocols, then the user at the end who doesn't really have the leverage is losing.
Sorry.
Yeah, sorry.
That's very important, because Microsoft didn't want to presentation.
And it kind of feels bad for how much is the studio?
So we do know, I think a couple people within Microsoft, but we didn't really have a lot of contact with them while we were working on it.
We, I think we would have been able to reach out if we needed help, but we didn't really, we didn't really find ourselves in that situation.
All right.
Thank you.