Here there!
At the RustFest Barcelona imps days, some of us met to have a chat about the mail library ecosystem in Rust. There's already a few crates that solve some of the problems one would encounter when trying to build a mail server, or any other tool that needs to handle and parse e-mail, but all of them are developed by different people and interoperability is difficult.
So we wanted to create a mail WG and we wrote a charter:
Rust Mail WG
This document outlines the basics of what it would require to start a Rust mail (e-mail) working group. Its contents should outline a charter, rationale and a roadmap.
Rationale
e-mails are cool and aren't going away (for better or worse) and we need safe mail libraries.
Charter
Goals
Rust has a lot of advantages over other languages with its memory and type safety. There are other language ecosystems that have great mail support, such as perl. There would be a real advantage to creating a safe mail ecosystem in Rust, potentially allowing many other language ecosystems to benefit from our efforts. This charter proposes to start a "Rust Mail Working Group" to facilitate this progress, and to get people who are already interested in working on mail libraries to work together on a common ecosystem.
Tasks & Activities
Create a Rust mail community
Working with mail is incredibly complex due to a series of old standards, some of which have been superseded, while old formats still need to be accepted. Many languages lack a strong mail ecosystem because of this reason. Right now the mail support in Rust is incomplete, making it hard to implement tools that work with mail in a strongly-typed manner.
One goal of this WG is to bring together people from the Rust community who are already working on mail libraries, but have so far not collaborated much to create a more solid ecosystem.
Develop an ecosystem
The primary goal isn't to aid others in the development of crates, but to be closer to the work mode of the embedded WG: it maintains and creates libraries. The mail WG aims to create a complete ecosystem of crates to do all things relevant to mail (sending, receiving, parsing, storing, loading, encrypting, decrypting, signing, and verifying signatures).
These features would be implemented in different sub-crates, which can get facaded via a central "mail" crate.
Creating a type safe, memory safe mail handling ecosystem in Rust would potentially be a huge advantage over other language ecosystems as well, which can more easily write bindings to Rust than to, say, perl.
Out of scope
To clarify, here are a few things we don't do and are not responsible for:
- we will not implement mail applications (servers and clients)
- we will not build semantic support for all media types, mail headers, authentication extensions etc.
Initial priorities
This section gives a summary of the topics and projects we are considering to be our initial priorities. These are topics that serve urgent, foundational needs.
Getting people involved in the WG
The first step is to advertise the working group. From talking to people at RustFest Barcelona as well as the internet it has been shown that many people are interested in solving the issues of dealing with mail.
Advertising the group, and getting interested people involved is a first important step to creating a good mail ecosystem, that is community maintained and tested, not just a few crate authors.
Implement header parsers
At a first session at RustFest it was concluded to use nom as a parser combinator framework across the ecosystem to parse mail and protocols alike. Because dealing with mail headers is difficult, starting by parsing the basic header fields into a parse-tree, then enabling other crates to do more with this tree is a good start. There are test suites in other mail libraries (namely the mail gem from Ruby) that can be ported to Rust to give us a solid foundation to build on.
Long term goals
This section gives a summary of the topics and projects we are considering to be our initial priorities. These are topics that serve urgent, foundational needs.
Create a comprehensive mail API
The "mail" crate is available to be re-used as an API facade, which would allow us to provide a unified interface for dealing with mail.
Creating a strongly-typed ecosystem
A problem with many other approaches and languages to dealing with mail is that dynamic languages (or approaches in Rust) make it harder on the developer of an application.
This would include things like a comprehensive MIME type crate, that can generate enum variants from the official IANA media types definitions or properly exposing header values as either lists or single values, without requiring the user of the mail crate to do that work instead.
First-class support for signed and encrypted mail
We don't expect every mail crate to validate and generate OpenPGP and S/MIME messages, but we would like to see first-class support for working with these types of messages. For instance, we'd like to see a MIME parser that makes it easy to work with signed OpenPGP messages even if the consumer of the message does not understand OpenPGP.
The next steps:
- Create an RFC to the
teamrepo, mainly to get access to a mailing list - Work on a more specific crate roadmap (which problems to solve, in which order)
- Put together some demo applications using the new APIs we create as a rolling test
Want to get involved? Post below or add yourself to the mailing list (coming soon)
