Released New-Tokio-Smtp v0.7.1

announcements
1

There is a new smtp crate using tokio: https://github.com/1aim/new-tokio-smtp

(The old tokio-smtp crate had to many things which changed with newer tokio
versions and a number of short comings so that "fixing" it meant rewriting it
completely)

There is an example in the readme which can be run with cargo run --example readme.

It will send a mail through smtp.ethereal.email (you need to provide account credential) which is a Mail Submission Agent (MSA) which wont deliver any mail and instead keeps them for debugging purpose).

This crate is focused only on the Simple Mail Transfer Protocol (SMTP) it does not handle anything wrt. to creating mails, parsing/validating mails and similar.

It is build in a way that libraries using it can define their own smtp commands like e.g. some version of the auth command provided by it or some other smtp command not yet provided.

It can be used on different "abstraction levels" from "I want to send exact this custom defined SMTP authentication command and handle the results myself" to "I have this encoded mail, please send it to smtp.example.com using this credential for auth".

While it's mainly focused on sending a mail to a MSA (Mail Submission Agent) it can be used for communicating with a MX, too. But that is not recommended (in generally independent of the SMTP library you use :wink:).

Currently there are some limitations (see the README) for example PIPELINING is currently not supported and there are only a handful of auth commands (also while it intentionally opts out from validating the mail it currently also opt out of validating mail addresses/domains as I have not yet fund a good created which
does only that and does it right...).

For opening connections there is a connection config which can be used to open all kind of relevant SMTP connections like (the example on Crates.io currently doesn't use it, through the version there already supports it):

  • connect using STARTTLS (and require it to succeed, to proceed with sending mails)
  • connect using direct TLS (while not a standard still a thing done)
  • connect with auth TLS (through strongly discouraged)
  • configure the TLS setup process to e.g. provide a client certificate
  • specify host by name or ip addres and port
  • have sensible default constructor (which is you provide a host name and it will
    return a builder with default port resolved IP address STARTTLS)
  • directly integrate authentication into the "connection setup part"
    • allow library consumers to define there own auth commands
      (sure it would be better just to provide any auth command in use at any place
      but there are a lot including a lot non standard ones and a lot of variations how some of them
      can be used :man_shrugging: ).

The current road map is roughly:

  1. for a 1.0.0 release following thinks need to be done:
    1. write or find a crate for validating mail addresses which
      works acceptable well
    2. implement PIPELINING support
    3. provide a view more common auth methods
    4. This crate is meant to only do smtp, so no connection pool and neither
      server not available retry it later logic belongs into it. But there should be
      a additional crate providing reasonable got impl. for this thinks. (Also this
      crate still made sure that you can have a connection pool, but only by
      implementing one, or bindings to a generic one can it be made sure that
      nothing was overlooked).
    5. implement at last prove of concept versions of BDAT to make sure the
      design can support it (yes, you can define and use your own BDAT command
      if you want to, just not with the helpers chaining commands for sending a mail
      together as they will by default use DATA)
  2. after this the roadmap would be
    • provide support for all even barely common auth methods
    • implement all common smtp commands (like e.g. BDAT)

While this sounds like a lot the current state is already quite usable and expect the Domain/PIPELINING changes most thinks should not be breaking changes (also PIPELINING should only brake the interface for defining custom commands, not the one for using them/sending mails).

2 Likes