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