mail-headers
Provides header specific functionality for the mail crate
This crate provides header specific functionality for the mail
crate. This includes:
HeaderName,HeaderandHeaderMapas for the general APIHeaderTryFrom,HeaderTryIntoas theTryFrom/TryIntotraits are not stable but we need something similar to their functionality.- a number of headers like
_To,_From,Sender,Subjectand many more (Note that_Toand_Fromare prefixed with and_to prevent name collisions when importing them, i.e. importing_From as Fromwould shadowstd::convert::Fromwhich can lead to extremely irritating errors). - a number of components which are used to represent the
content/field body of an header field e.g.
MailboxListorEmail. They are placed in thecomponentsmodule. - a
headers!macro for making the creation of anHeaderMapwith a number of headers easier. - a
def_headers!macro for defining new custom headers
Example (HeaderMap)
A header map is a collection representing a number of mail headers in an specific order. It can be created like this:
extern crate mail_headers;
// just import all headers
use *;
use ComponentCreationError;
Example (custom header)
If needed users of the mail crate can create their own
headers, through this should be done with care.
Note that the second field (then unchecked { <name> }),
expects a specific naming scheme, the auto-generated test
do check if it's violated but if you just run the code and
ignore the failing tests strange error can occure. (
The scheme is a capitalise the first letter of each
word and write all other letter in lower case, i.e.
X-Id is ok but X-ID isn't). The reason for this is because
of the way the header does the field lookup. While this
is not nice, for most use cases there is no need to
generate custom headers and in the future this might be
circumvented by auto-generating the name with a proc-derive.
extern crate mail_headers;
use components;
// this will define two headers `XFooEmail` and `XBarMailbox`
// the first will add a header field named `X-Foo-Email` with
// a value which is an `components::Email` and the second will
// add field with a value which is an `components::Mailbox`.
//
// Note that through the way they are defined `XFooEmail` can
// at most appear 1 time in an header map, while `XBarMailbox`
// can appear multiple times. Be aware that this is checked through
// so called validators which needs to be explicitly run, which they
// are if this header map is used to create a mail (running them
// when adding fields would be a mess as you would have to add
// transactions which can add/remove multiple fields at once, and
// implementing auto-generation for some fields which are required if
// some other fields are given in a certain way would be harder too).
// If in scope both can be used in the `headers!` macro,
// like any other header.
//
def_headers!
Documentation
Documentation can be viewed on docs.rs. (once it is published ;) )
License
Licensed under either of
- Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
- MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)
at your option.
Contribution
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.