Gluon 试图弥合这一差距并克服现有开源 IMAP 库中的局限性。
瑞士公司 质子股份公司， 开发 Proton Mail 和 Proton VPN 服务， 最近介绍了 Gluon IMAP 库, 设计 p创建您自己的 IMAP 服务器. 该库非常出色，因为它支持 IMAP4rev1 (RFC-3501) 协议，并且包含在新版本的 Proton Bridge 服务中。
在开发过程中，重点是实现的正确性、稳定性、可靠性、开发人员的易用性和高性能。
关于 Gluon IMAP
有人提到 原因 创建 IMAP 协议的新实现 是对可靠和高性能解决方案的渴望 可以处理大邮箱。 据 Proton Mail 的开发人员称，现有的开源 IMAP 库遇到了维护问题或无法扩展。
我们编写 Gluon 的第一步是根据 RFC3501(new window) 中给出的语法生成一个 IMAP 解析器。 我们使用 ANTLR4(new window)，一个流行的解析器构建器，来创建一个可以根据规范解析 IMAP 命令和响应的解析器。 这使我们能够专注于实现 IMAP 协议的逻辑，而不是解析和验证输入。
Gluon 也适用于多个客户端。 同时，例如，当用户通过 Web 界面查看邮件并同时使用单独的邮件客户端时。
组织此类工作的复杂性是由于 IMAP 客户端通常使用邮箱中消息的序号来标识邮件消息，但是当一个客户端删除消息时，序号会发生变化，而另一个客户应将此更改考虑在内帐户。
在这种情况下，服务器会向客户端发送更改通知，但在确认该通知之前，服务器必须确保已正确解释所传输命令中的消息编号。
电子邮件需要可靠，但也需要高性能，尤其是在过去十年中典型收件箱的大小显着增长的情况下。 许多开源 IMAP 实现倾向于针对一个而不是另一个进行优化，从而导致相当大的错误或权衡。
为了解决这个问题，以及 组织来自客户端的多个并行连接的处理， 胶子 实现快照机制。 这种机制的要点是 Gluon 将自己的邮箱快照分配给每个客户端。
每个快照都反映了与客户端关联的邮箱的唯一视图，该视图保留其状态并确保序列号保持不变，而不管其他客户端采取的操作。
Gluon 跟踪两种邮箱状态：持久和会话。 持久状态反映消息在所选邮箱中的实际位置，而会话状态反映每个客户端对邮箱内容的看法。
同步状态 几个连接的客户端之间的每个会话， Gluon 使用“响应者”系统。 这些是封装状态更改的类型，在执行时会转换为 IMAP 响应。
当客户端执行会更改另一个客户端状态的操作（例如将消息标记为已读）时，后端会为该操作创建一个响应程序并将其推送到受影响的状态。 受影响的状态保持不变，直到响应程序被执行，此时它被更新并且相应的 IMAP 响应被发送到客户端。
这种方法允许 Gluon 在每个会话的基础上有效地管理状态，同时确保跨多个客户端的一致性。
最后，提到国家 IMAP 存储在支持 SQL 的 DBMS 中. 翻译成 Gluon 的 Proton Mail Bridge 服务的 Beta 测试表明，使用 IMAP 的速度显着提高 (1000%)。 库代码是用 Go 编写的，并在 MIT 许可证下分发。
如果您有兴趣了解更多，可以查阅详情 在下面的链接中。