Facade which re-exports functionality from a number of mail related crates.
The facade should re-export enough functionality for using the mail carate to create/modify/encode mail, send them over smtp (feature) or use a handlebars based template engine to create them from a template (feature).
Functionality steming from following crates is re-exported:
mail-headersprovides implementations for the headers of the mail. This also includes a number of header components which appear in mail header bodies but are also re-used in other placed (e.g.
MediaTypestemming from the
Content-Type header orDomain`).
new-tokio-smtpto make it easier to send mails over smtp. This also includes functionality to automatically derive the smtp sender/receiver from the mail if no sender/receiver is explicitly given (Smtp by it's standard does not use the
Toheaders of a mail. Instead it treats the mail, including it's headers mostly as a opaque block of data. But in practice the addresses in
Sendertend to match the smtp sender/recipient).
mail-templateprovides a simple way to bind template engine to generate mails. It has a feature which if enable directly includes bindings to
handlebars. This feature is re-exported in the crate as the
mail-internalsprovides some shared mostly internal parts the other crates use. This is normally only needed if you write your own mail header implementations. But even then the does this crate re-expost the parts most likely needed (in the
Creates and encodes a simple mail without using any fancy helpers, templates or similar.
Uses the bindings for the
handlebars template engine to create a mail, including
alternate bodies and an attachment.
A simple program which queries the user for information and then sends a (simple) mail to an MSA (Mail Submission Agent). While it is currently limited to STARTTLS on port 587, Auth Plain and only simple text mails this is a limitation of this cli program not the mail libraries which can handle other forms of connecting and authenticating etc.
Note that this is meant to send data to an MSA NOT a MX (Mail Exchanger), e.g.
smtp.gmail.com is a MSA but
gmail-smtp-in.l.google.com is an MX. Also note
that some mail providers do not accept Auth Plain (at least not without
enabling it in the security settings). The reason for this is that they prefer
that applications do not use username+password for authentication but other
formats e.g. OAuth2 tokens.
Rest assured that the authentication data is only sent over a TLS encrypted
channel. Still if you don't trust it consider using some throw away or testing
mail service e.g.
Lastly the examples uses the same unique seed every time, which means that
Message-ID's, and Content-ID's are not guaranteed to be world unique even
through they should (again a limitation of the example not the mail crate).
Nevertheless given that it also doesn't use its "own" domain but a
domain it can't guarantee world uniqueness anyway and would fail many spam filters,
so if you use it make sure to change this to the right values for your use
Provides bindings to
mail::smtp by reexporting the
mail-template engine implementation using the
crate. It can be found under
traceing debugging functionality in the
mail-internals, this is only used for testing header implementations
and comes with noticeable overhead. As such this should not be enabled
except for testing header implementations. Also
re-exported as it can be seen as an internal part of the implementation
which normally doesn't need to be accessed directly.
This module provides utilities for composing multipart mails.
Provides the context needed for building/encoding mails.
This module provides an number of default implementations for some of the interfaces.
Re-export of the default_impl parts from
Module containing all custom errors produced by this crate.
re-export of all error types
This modules contains all components provided by this library.
This module provides the encoding buffer.
Module containing the
Module containing some utilities for MIME usage/creation.
Defines a new header types with given type name, filed name and component
Create a header map from a list of header's with ther fields
A type containing some data and metadata for it.
an email of the form
a mail with all contained futures resolved, so that it can be encoded
A header map is a collection representing a number of mail headers in an specific order.
Note: Normally you will never have the need to create a HeaderName instance by
yourself (except maybe for testing). At last as long as you use
A minimal IRI (International Resource Identifier) implementation which just parses the scheme but no scheme specific part (and neither fragments wrt. those definitions in which fragments are not scheme specific parts).
A type representing a Mail.
A future resolving to an encodable mail.
POD type containing FileMeta, Content-Type and Content-Id
POD containing the IRI which should be used to laod a resource well as an optional file name to use and a description about how the content type should be handled.
A type which either represents a single body, or multiple modies.
Specifies what kind of mail we want to create.
A enum specifying a "resource" for a mail.
Hint to change how data should be transfer encoded.
Specifies how the content type should be handled when loading the data.
a utility trait allowing us to use type hint structs
Trait representing a mail header.
Type alias for HeaderObjTrait's trait object.