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
team repo, 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)