#email #rfc5322

email-format

Email message format (parser and data structure)

12 releases (6 breaking)

0.7.0 Mar 29, 2019
0.6.0 Oct 13, 2017
0.5.0 Oct 12, 2017
0.4.0 Mar 11, 2017
0.2.0 Nov 28, 2016

#25 in Email

Download history 5/week @ 2019-01-17 8/week @ 2019-01-24 2/week @ 2019-01-31 2/week @ 2019-02-07 1/week @ 2019-02-14 4/week @ 2019-02-21 26/week @ 2019-02-28 5/week @ 2019-03-07 1/week @ 2019-03-14 39/week @ 2019-03-21 27/week @ 2019-03-28 18/week @ 2019-04-04 8/week @ 2019-04-11 2/week @ 2019-04-18 6/week @ 2019-04-25

63 downloads per month
Used in 1 crate

MIT/Apache

171KB
4.5K SLoC

email-format

"Internet Message Format" meticulously implemented for email construction and validation, as defined in RFC 5322 and other RFCs.

Documentation (released)

Documentation (master)

Features

  • Parses bytes into an Email structure (represented internally as a tree) and validates RFC 5322 "Internet Message Format" compliance.
    • Extensive RFC 5322 Parser/validator: If you generate an email using this crate, you are guaranteed that will be a valid RFC 5322 formatted email, or else you will get a ParseError. The only exception that I am currently aware of is that lines can be longer than 998 characters (see issue #3).
  • Streams an Email structure back into bytes.
  • Generates and modifies Email structures using functions like set_subject(), get_from(), clear_reply_to(), add_optional_field(), etc.
  • Integrates with lettre (enable optional feature lettre) and mailstrom
  • Supports chrono DateTime and time Tm for setting the Date field (enable optional feature chrono and/or time)

Limitations

  • Valid emails are 7-bit ASCII, and this crate requires all content to be 7-bit ASCII. The proper way to send richer content is to use a transfer encoding, and to set a content-transfer-encoding header. We don't yet offer any help in this regard, beyond the ability to add_optional_field(). You'll have to manage the encoding yourself. We plan to add convenience functions for this eventually (see issue #19)
  • Obsolete email formats are not implemented in the parser. Therefore, it is not sufficient for parsing inbound emails if you need to recognize formats that were obsoleted in 2008.

Plans (not yet implemented)

  • Support for content-transfer-encodings (unicode via Quoted Printable or Base64 or otherwise)
  • Support for email headers defined in other RFCs:
  • Support for MIME (RFC 2045, RFC 4021, RFC 2231, RFC 6352) using mime_multipart
  • Support for streaming of MIME parts from disk.

History

This project was inspired by the earlier email crate, but was reworked from scratch due to a number of significant differences in design, implementation and interface.

License

Licensed under either of

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.

Dependencies