Gluon seeks to bridge that gap and overcome limitations in existing open source IMAP libraries.
The Swiss company Proton AG, which develops the Proton Mail and Proton VPN services, recently introduced the Gluon IMAP library, designed pto create your own IMAP servers. The library is remarkable as it supports the IMAP4rev1 (RFC-3501) protocol and is included in the new version of the Proton Bridge service.
During development, the focus is on implementation correctness, stability, reliability, ease of use for developers, and high performance.
About Gluon IMAP
It is mentioned that the reason to create a new implementation of the IMAP protocol is the desire for a reliable and high-performance solution that can work with large mailboxes. According to the developers at Proton Mail, existing open source IMAP libraries experienced maintenance issues or did not scale.
Our first step in writing Gluon was to generate an IMAP parser from the syntax given in RFC3501(new window). We used ANTLR4(new window), a popular parser builder, to create a parser that could parse IMAP commands and responses according to the specification. This allowed us to focus on implementing the logic of the IMAP protocol instead of parsing and validating input.
Gluon also works fine with multiple clients. at the same time, for example, when a user is viewing mail through the web interface and using a separate mail client at the same time.
The complexity of organizing such work is due to the fact that IMAP clients generally use the sequence numbers of messages in the mailbox to identify mail messages, but when one client deletes a message, the sequence numbers change and the other customer should take this change into account.
In such a situation, the server sends a change notification to the clients, but before acknowledging the notification, the server must ensure that the message numbers in the transmitted commands are interpreted correctly.
Email needs to be reliable, but it also needs to be high-performing, especially since the size of the typical inbox has grown significantly over the past decade. Many open source IMAP implementations tend to optimize for one and not the other, leading to fairly large bugs or tradeoffs.
To solve this problem, as well as to organize the processing of several parallel connections from a client, gluon implements the snapshot mechanism. The gist of this mechanism is that Gluon assigns its own mailbox snapshot to each client.
Each snapshot reflects a unique view of the mailbox associated with the client that preserves its state and ensures that the sequence numbers remain the same, regardless of actions taken by other clients.
Gluon keeps track of two mailbox states: persistent and session. The persistent state reflects the actual position of the messages in the selected mailbox, while the session state reflects each client's view of the mailbox contents.
To sync status per session between several connected clients, Gluon uses a system of "responders". These are types that encapsulate a change of state and, when executed, are converted to IMAP responses.
When a client performs an action (such as marking a message as read) that would change the state of another client, the backend creates a responder for the action and pushes it to the affected state. The affected state remains unchanged until the responder is executed, at which time it is updated and a corresponding IMAP response is sent to the client.
This approach allows Gluon to efficiently manage state per session while ensuring consistency across multiple clients.
Finally, it is mentioned that the state IMAP is stored in a DBMS that supports SQL. Beta testing of the Proton Mail Bridge service, translated to Gluon, showed a significant (1000%) increase in the speed of working with IMAP. The library code is written in Go and is distributed under the MIT license.
If you are interested in knowing more about it, you can consult the details In the following link.