Introduction to the Modern Email DevRoom
There are almost half a dozen new opensource webmail systems that you can host yourself now, after a decade of little development. One of them is so good that after testing it for my work, I've grown to use it almost every day privately. Several of their developers attend FOSDEM this year and may talk about their software in depth, this talk covers them as a group. It's mostly for an audience that (may) want to self-host (again).
What sets the new webmail systems apart from the old ones, how do they compare to Google's and Microsoft's polished offerings, how do they compare to each other? I'll talk about all of that, and since I am a standards wonk there is a risk that I may digress into how well or badly they use the standards.
I'll mostly talk about Snappymail¸Alps, Kurrier and Mox.
OpenCloud is a production-ready Open Source "Drive" solution for storing and sharing files, and we are adding a Groupware stack to all that.
We'd like to present our concept (especially regarding the integration of the other services in our stack, namely OpenCloud Drive and OpenTalk) as well as what we have so far in terms of our implementation, which extensively uses JMAP in its middleware, in combination with a Stalwart backend that does a lot of the heavy lifting.
The whole stack is Open Source, implemented in Go and TypeScript.
Parula: Updates on the progress
In 2025, Thunderbird did something it hasn't done in over 20 years, since before even its first stable release in 2004: it grew built-in support for a new email platform. This new platform is Microsoft Exchange, the backbone of some of Microsoft's biggest communications and productivity tools.
This talk will briefly go over the step we took to try to define how to support new platforms and protocols in an old code base, and the challenges we encountered as we worked our way towards full email support for Exchange in Thunderbird.
An update to my 2018 KDE Kontact / E-Mail talk showing the status and problems of an enterprise user of Kmail and Co. This was eight years ago, let's check what has changed and where we need to do better:
https://www.youtube.com/watch?v=H8SVe6wISmY "Having been a KDE user almost from the start, over the years I have learnt lots of troubleshooting, hacking and optimizing settings in Kmail, Kontact, KDE and Akonadi. And I would like to share and learn more :-)
I am using Kontact on a daily basis, in an environment with lots of E-Mails and Gigabytes of data and e.g. a variety of calendars. Three mail accounts, three different IMAP-Servers, five+ desktops to take care of, archiving, filtering, calendaring, using Kontact keyboard-only (almost), in mailing lists, searching, per-folder settings, import/export of data,
I want to share my insights and get a discussion going - hopefully with the audience - that this presentation might spark with the goal of making Kontact(Kde-PIM) better. There's no other working Enterprise level Mail/Groupware Client for Linux with so many great features.
I learnt a lot about debugging Kontact and Kmail for my needs, and even fixing with some akonaditools. I would love to present my findings and I hope to get a discussion going - with some developers? - how to:
use
troubleshoot
quick setup
copy
revert/purge
Akonadi directories, Kontact, KDE and Kmail settings and files. Akonadictl, Akonadiconsole, Baloo, ...
A fast-forward dialog about the state of email and security.
In our talk we will point out real examples and funny stories as well as some interesting tools and how to combine them into a holistic mail security concept.
We will cover famous things like the need of unencrypted Pop3, FOME - the fear of missing email, postmasters nightmare with dmarc, dkim, spf in between security and comfort focused users, arc - the layered chain of postmasters of trust - and many more. Yes, something with AI.
It's not as bad as it maybe sounds.
Additionally we will talk about the perfect Ratatouille for mail infrastructures - covering various established and exciting new flavors and spices. In other words, how to tie up open source components for a perfect mail security infrastructure.
Even Signal took years to get it right, and Matrix is not quite there yet: Implementing a multi-device chat system that supports not only reliable encryption, but also reliable deletion of messages also known as "Forward Secrecy".
In this talk we'll present a new "Autocrypt 2 certificate" specification draft, that originated from the chatmail community and its supporters. The draft is built upon the modern RFC9850 OpenPGP standard and aims to to supports encryption that is safe against attackers that collect all in-transit traffic and then
try to use a prospective future Quantum computer to decrypt all collected messages, or
try to recover deleted messages after they get hold of a device/private key.
The draft Autocrypt2 certificate specification is designed to be usable by any Internet Messaging system and is intended for submission to IETF early 2026.
This talk covers Rspamd development from March to December 2025, focusing on four major areas. First, HTML fuzzy hashing - a new algorithm that generates structural fingerprints from DOM trees, enabling detection of phishing emails that reuse legitimate templates with modified links. Second, multi-class Bayesian classification that extends the traditional spam/ham model to support up to 20 categories (newsletters, transactional mail, promotions) with single-call Redis lookups. Third, protocol improvements including TCP transport for fuzzy queries and encrypted ZIP archive handling via libarchive. Fourth, neural network refactoring into a provider-based architecture for combining multiple feature sources. We'll also discuss practical experience using LLM tools for code generation, documentation, and PR review during this development cycle - what worked, what didn't, and where human judgment remains essential.
Cascading Style Sheets (CSS) enable visual customization of HTML emails. However, this flexibility comes at a cost: in this talk, we reveal how CSS creates serious privacy and security vulnerabilities. We demonstrate that CSS facilitates fingerprinting and tracking in HTML emails, even undermining the privacy protections offered by email clients that use proxy services to access remote resources. These tracking capabilities enable targeted phishing and spam campaigns.
More critically, we present a novel scriptless attack that exploits container queries, lazy-loading fonts, and adaptive ligatures to exfiltrate arbitrary plaintext from PGP-encrypted emails. The attack targets mixed-context scenarios—cases where email clients render both trusted (encrypted) and untrusted (attacker-controlled) HTML content within the same message view. We successfully demonstrate end-to-end exfiltration of PGP-encrypted text from Thunderbird, along with two other major email clients that permit such content mixing.
These findings expose fundamental gaps in current isolation mechanisms, demonstrating that post-Efail mitigations remain insufficient against CSS-based attacks.
Email service is at the core of a collaborative suite. And, good news, FOSS solutions for all collaborative uses have an unprecedented maturity. But Europe still faces a critical dependence on Office 365, with strategic and financial costs that are now undeniable.
The challenge is no longer functional, FOSS solutions suffer from an architectural limitation : a simple SSO does not create a platform. To offer a true Smart Platform Experience around the mail, we must go beyond silos solutions and build deep, consistent, cross-functional integration between independent services.
Based on the integration of DINUM's LaSuite into Twake.AI, we will analyze what is missing to offer a “Smart Platform Experience”: a standardized cross-functional layer that brings together independent services.
Samuel Paccoud, director of lasuite.numerique.gouv.fr, will comment this integration and the perspectives he identifies.
We will see how such a standard can enable a modular ecosystem, where each application remains independent but can interoperate deeply, forming a credible and sustainable sovereign workplace. This is the mission of the Open Buro consortium: to create an open foundation where architecture becomes a political act.
Messages is a project from ANCT, a French government agency that aims to bring secure and modern tools to small rural towns.
In this talk we'll introduce the MIT-licensed project and explain how the specific requirements of public servant inboxes led to a unique design, breaking free to legacy protocols like IMAP.
If you're following along with email standards, you know about JMAP: it replaces both IMAP and SMTP-for-sending, eliminating a lot of weird and dated protocol design with HTTP and JSON. It makes easy things easy, and also enables fast, efficient offline synchronization. It's not a new email system, just a new access protocol.
But did you know that JMAP can also handle your calendars, your address book, your files, and plenty more things to come? This talk will describe JMAP extensions for those systems: what they are, how they work, and why you should be excited.
Ever wondered how Gmail, Yahoo, and Apple iCloud manage to host hundreds of millions of email accounts reliably? How do they store petabytes of messages, survive hardware failures without losing data, and keep spam at bay across billions of daily deliveries?
This talk explores how to design and operate a large-scale email system using Stalwart, an open-source mail server built from the ground up for distributed deployments. Using a 1,024-node cluster as a concrete example, we will examine the architectural patterns that make planet-scale email possible, and how similar approaches are used by providers such as Apple iCloud.
The session covers the full stack of distributed email challenges: storing and indexing messages across a cluster, running spam and phishing filtering at scale without becoming a bottleneck, managing distributed MTA queues for reliable delivery, and load balancing IMAP, JMAP, and SMTP traffic across nodes. We will also look at how Stalwart handles cluster coordination, orchestration, and autoscaling, how to reason about failure scenarios before they occur, and how to adapt a deployment to fluctuating load in dynamic environments.
Attendees will leave with a practical understanding of how modern distributed email systems are built and operated, and how to apply these principles using open-source technology.
Traditional email servers were designed for a different era. They work great for small deployments but struggle at scale: Maildir breaks at 100k+ users, configuration changes require service reloads, and a single blacklisted IP blocks everyone on the server.
WildDuck takes a different approach. Built on MongoDB and Node.js, it treats email as a modern distributed systems problem. This talk explores the architectural decisions behind WildDuck and the lessons learned running it in production with 100,000+ accounts.
Dovecot 2.4 removed one of the mail server's most outstanding features: being able to replicate between two servers, even in an active-active scenario if desired. The actual sync code stays in place, but the replication orchestrator was removed.
On the other hand, the same release introduces improvements to two APIs: the event API now allows reacting to pretty much anything happening in Dovecot using an HTTP server, while the doveadm HTTP allows to trigger synchronization with another server.
We'll have a look on Dovecot 2.3's implementation of replication, checking out alternative solutions to replication to finally look into a Golang-based solution that does not require forking the mail server codebase.
Gatling is a framework for performance testing and Apache James contributors had been providing a DSL (Domain Specific Language) for easily writing IMAP performance tests. We also wrote JMAP benchmarks using Gatling.
This talk will cover the inner working of Gatling, the architecture of the IMAP DSL, key contributions to Yahoo's imapnio library, the toolbox for performance testing Apache James (including provisionning data), and present related results.
We will also present how it completes other performance-related tools of the Apache James eco-system: Grafana metrics, async-profiler flame graphs (and contributions to the FOSS eco-system it did lead to!), JMH (Java Micro-benchmark Harness) tests for MIME4J...
This talk I will go over some FOS (online) tooling to check your mail config. Some common misconfigurations in DNS. Why you should probably want to avoid www CNAME @, and how to config other observations from the biannual measurements of scanning more than 10.000 governmental host names in The Netherlands. After this talk you'll know at least one DNS or security improvement for your own or organization domain, or something to monitor for your email.
Online tools: - the free open source Internet.nl (in the project team) [IPv6, DNSSEC, SPF, DMARC, DKIM, STARTTLS, DANE inbound] - the free open source haveDANE.net (adopted/hosted by platform behind internet.nl) [interactive DANE outbound] - the free open source zonemaster.net [DNS] - the free open source DNSViz.net [DNS]
Run yourself: - the free open source spftrace [SPF] - the free open source testssl.sh [STARTTLS]
And a split second for some links to non FOS tooling that is useful, and maybe be made open source (there is no sell of a product nor ads), or should be re-created: - https://www.email-security-scans.org - https://www.huque.com/bin/danecheck-smtp - https://dane.sys4.de
(Free but commercial that needs a FOS alternative: https://www.mail-tester.com & https://emailspooftest.com)
In 2025 I gave a 45 minute talk on WHY2025 How (not) to configure your domainname [internet.nl] (recording) about internet standards / misconfigurations in both website and email space. In this talk I want to focus on the mail part and (online) free open source tooling to check your mail config.
This presentation will touch on: - DNSSEC (RFC 4033 and many more), some common failures (e.g. CNAME's) - why not CNAME to your apex domain (if you have an Mx record) - use Null MX (RFC 7505) (if you don't use mail on a hostname) - why configuration SPF (RFC 7208) on all hostnames - why there are more reasons to avoid CNAME's - why enable DANE (RFC 6698) and TLSRPT (RFC 8460) and why it's superior to MTA-STA (RFC 8461), how to rotate DANE - why monitoring matters (IPv6, DANE, SPF, etc.)
I'm the maintainer of a very popular email client library, PHPMailer, and have found that it's difficult to test reliably because mocks get overcomplicated and unrepresentative, and it's difficult to configure mail servers to produce specific errors, for example to test what happens in your client if the server rejects a message with an unknown user, greylisting, spam filter, or authentication failure response. To this end I have created BadSMTP, a mail server written in Go that produces specific errors on demand, easily driven by client configuration alone. It's a single, standalone binary, designed to run in CI systems, or as part of a larger system along the lines of mailhog. Essentially I want to do for SMTP what badssl.com does for TLS. This talk is a simple overview of the project, why it was needed, and how to use it.
This talk will cover the context, origins, and core concepts of the Plan 9 operating system.
It will focus around Plan 9's high-level ideas that make it unique, and fundamentally different from Unix. This includes files, namespaces, the 9p protocol, networking, graphics, and the limitless potential of file servers, which can only be achieved due to its design.
I will aim to provide a genuine understanding of Plan 9's approach; not just what the concepts are, but why they exist and how they solve real problems that traditional Unix cannot.
Although this talk assumes familiarity with Unix-like systems, it is not required to understand what will be presented. In fact, heavy assimilation with Unix tends to be a handicap rather than an advantage.
GEFS is a new file system built for Plan 9. It aims to be a crash-safe, corruption-detecting, simple, and fast snapshotting file system, in that order. GEFS achieves these goals by building a traditional 9p file system interface on top of a forest of copy-on-write Bµ trees. It doesn�t try to be optimal on all axes, but good enough for daily use.
Over the past two decades, Plan 9 has seen many improvements and contributions and been made accessible on modern hardware by projects such as 9front. While appealing for certain tasks, audio processing has not been in the spotlight much. Despite the many ports and tools now available, information about them is splintered across many websites and code repositories and it can be difficult to piece together the overall picture. In particular, Plan 9 typically isn't known for music production, yet while it cannot approach the feature set of modern digital audio workstations (DAWs) on other systems, it is quite capable. This talk will explore the topic of audio processing on Plan 9 from a musician's perspective, show what can be done currently, and discuss its limitations and needs. Basic knowledge of Plan 9 is assumed. Topics covered: driver support, decoding/encoding, audio players, recording and editing, visualization, MIDI tools, trackers, synthesis, production.
The ongoing digitalization has made cloud services and data centers the backbone of significant parts of our modern society and economy. Thus, exposing more and more sensitive data to a plethora of novel threats, both in terms of security and safety. However, most of today's cloud infrastructure runs on monolithic system software that makes it hard to harden against security leaks or unwanted outages by relying on too coarse-grained capabilities or having to orchestrate multiple security enforcement systems simultaneously. Even worse, solutions meant to improve performance or mitigate interference from co-located workloads can increase security risks by weakening or circumventing OS security policies. With capabilities, modern microkernels offer fine-grained access control via a single enforcement mechanism, while moving system services to the user space mitigates the failure of individual services and prevents a total system failure. However, despite their advantages, microkernels have seen little adoption among cloud service providers. This talk will present the benefits of a cloud architecture based on a microkernel and discuss the challenges of building such an architecture on a modern microkernel through the example of a prototype based on the Genode Operating System Framework.
NOVA is a modern open-source (GPLv2) microhypervisor that can host and harden unmodified guest operating systems. NOVA is typically accompanied by a component-based OS that runs deprivileged and implements additional functionality, such as platform services and user-mode device drivers.
Over the years, the interrupt subsystem of modern client and server platforms has evolved significantly, by (1) scaling up from only a few pin-based to thousands of message-signaled interrupts and (2) scaling out the delivery of those interrupts across dozens or hundreds of CPU cores.
Architectural differences between ARMv8-A and x86_64, such as
pose a challenge to the design of a uniform API for managing interrupts and devices and motivated the introduction of a new type of kernel object in NOVA: Device Contexts
After a brief discussion of NOVA features added recently, the majority of the talk will focus on NOVA's new interfaces for managing hardware devices and interrupts.
Links:
This talk gives an overview of skiftOS’s architecture, focusing on its microkernel core and service model. It explores the design trade-offs behind keeping the kernel minimal yet practical, and the lessons learned from building a complete, usable operating system on top of it.
The session is aimed at developers interested in microkernels, operating system internals, and the challenges of scaling a small core into a functional ecosystem.
Project Repo: https://codeberg.org/skift/os
The Genode OS Framework is certainly not a newcomer but still under very active development. While the framework supports various third-party microkernels, its custom-tailored base-hw kernel has proven valuable for putting Genode-specific (kernel) concepts to the test. One of those concepts that we have been test-driving for about a decade was the quota-aware CPU scheduling, which combined CPU-quota trading with priority-based scheduling. However, with Sculpt OS as a major use case of Genode as a desktop OS that focuses on dynamic workloads, it was time to rethink what we expect from a kernel's CPU scheduler.
In this talk, Johannes Schlatow and Stefan Kalkowski share the story and lessons learned from re-designing and re-implementing the kernel scheduler with a particular focus on fairness, tunable latency and ease of configuration.
Redox is a Unix-like microkernel operating system, community developed and written in Rust. Funded through NGI Zero Commons and NLnet, Redox is developing Capability Based Security as a fundamental part of interprocess communication and file I/O. This presentation will look at our strategies for implementing capabilities, POSIX file descriptors, namespaces, containment, and escalation.
As kernels manage hardware, in certain cases the only way to prevent race conditions in kernel code is to disable interrupts. This is a kernel way of granting code exclusive access to resources at lowest levels.
In the realm of embedded devices, it is often not feasible to keep interrupts disabled for prolonged period of time. This affects the design of portions of the kernel which modify data structures accessible from within interrupt context. Despite very limited API offered by the kernel to interrupt handlers, this still affects key data structures in kernel - scheduler table and notification table. This in turn means that any use of threading or notification API would require interrupts to be disabled for potentially prolonged time periods.
To avoid prolonged periods of disabled interrupts we went for some inspiration into the land of lock-free and wait-free programming. We took basic primitives used in lock-free programming and modified them to avoid excessive overhead such primitives have. The resulting mechanism is not lock-free anymore yet offers semantics which allows us to lock (disable interrupts) for much shorter and well predictable periods of time.
The resulting mechanism resembles database transactions to certain extent. This talk will provide introduction to the transaction subsystem, reason on why it offers benefits over raw locks and elaborate on the topic "How not to loose your hair while trying to work with ever-changing data consistently".
This presentation describes the technical implementation of PhantomOS, an orthogonally-persistent operating system, on modern microkernel architecture using the Genode framework. The talk center on the engineering challenges encountered during the porting process, especially the adaptation of the core persistence mechanisms. The talk will also touch on work on network persistence and the added WASM runtime.
As part of the port, the snapshot process was reworked and separated into its own Genode component. The talk will cover how the component utilizes backlink data structures and CRC validation to achieve efficient state storage with minimal overhead. A live demonstration will showcase the reliability and performance characteristics in a real-world environment.
axle OS (GitHub, blog) is a hobby microkernel and userspace which includes many home-grown utilities such as an x86_64 assembler + ELF linker, a TCP/IP/(ARP/DNS/NIC/etc)]( stack, SATA support, a TrueType renderer, a GameBoy emulator, and more. Everything is built around message passing, from process launches and virtual memory operations, to driver events and GUI updates.
axle OS lacks a GPU driver, but features a compositing desktop window manager with transparency effects and animations. Since the compositor runs on the CPU, I’ve put significant effort into making redraws as efficient and targeted as possible to create a smooth and responsive experience.
In this talk, I’ll give a tour of axle’s CPU-bound compositor from first principles. We’ll go on a journey of live visualisations, seeing how each successive optimization allows the compositor to perform progressively less work per frame, building up towards a general strategy for redraws that comprehensively covers screen updates.
Developing a compositor that plays optimisation tricks involves lots of testing, which can be onerous in an OS that’s primarily developed in an emulator and which must boot itself before the compositor can run. Therefore, we’ll also take a look at a host-side userspace harness I made for the compositor: the compositor can run on my host-native macOS, or as a part of the full axle OS distribution. I developed a simulator which allows me to record user interaction (such as dragging a window around with a mouse), capture the composited frames, and write a test suite that replays these events and ensures the composited frames don’t deviate from the correct output.
We’ll investigate R-trees, different compositing strategies, client request rate limiting, and the various types of redraws that the compositor must be able to handle. This talk aims to be an engaging and ‘interactive’ experience for the audience, with lots of guiding visualisations motivating each optimization we make to our compositor, following the journey towards axle OS’s contemporary CPU compositor.
It has been a while since the last FOSDEM update on GNU/Hurd, so we have a lot to talk about :)
Driver support improvement is on its way through using netbsd's rump layer, now being used in production although there are a few things left to fix. Some SMP support has been added, which should allow at least compilation to be run in parallel. Hurd support was added to the rust ecosystem, which became more and more a necessity due to various software now requiring it. The x86_64 port is essentially complete, which mostly required fixing the MIG RPC layer, and telling various software that it exists. To bootstrap the Debian GNU/Hurd x86_64 distribution, many of the crossbuilding, rebootstrapping and build profiles tools were used to make it relatively smooth. Additionally, the Guix/Hurd distribution is also on its way, as well as an Alpine/Hurd distribution. And more to discover during the talk!
Since the first Microkernel OS Devroom at FOSDEM 2012 and culminating today, there have been exactly 15 devrooms in 15 years dedicated to microkernel-based operating systems at each FOSDEM. As surprising or shocking this may sound to somebody who has been there all along, this time period already constitutes a small piece of history. While the computing world of today is not dramatically different or unrecognizable compared to 2012, maybe except for a few "minor" technologies such as HTML5 and LLMs ;), there have definitively been some changes and shifts of priorities.
Let us take this opportunity for a small retrospective of the last 15 years in the context of open-source microkernel-based operating systems. What problems have we been facing back then and how do they relate to the problems we face today? What have been the ups and downs? What are the important lessons learned?