email-format

"互联网消息格式"精心实现，用于电子邮件构建和验证，如 RFC 5322 和其他 RFC 中定义。

文档（已发布）

文档（master）

功能

• 解析 字节到 Email 结构（内部表示为树）并验证 RFC 5322 "互联网消息格式" 符合性。
  • 广泛的 RFC 5322 解析器/验证器：如果您使用此 crate 生成电子邮件，则保证该电子邮件将是有效的 RFC 5322 格式，否则您将获得 ParseError。我目前所知的一个例外是行可以超过 998 个字符（见问题 #3）。
• 将 Email 结构流回字节。
• 使用 如 set_subject()、get_from()、clear_reply_to()、add_optional_field() 等函数 生成和修改 Email 结构。
• 与 lettre（启用可选功能 lettre）和 mailstrom 集成
• 支持 chrono DateTime 和 time Tm 用于设置 Date 字段（启用可选功能 chrono 和/或 time）

局限性

• 有效的电子邮件是 7 位 ASCII，此 crate 要求所有内容都是 7 位 ASCII。发送更丰富内容的正确方法是使用传输编码，并设置 content-transfer-encoding 头。我们尚未提供这方面的任何帮助，除了添加 OptionalField() 的能力。您将不得不自己管理编码。我们计划最终添加便利函数（见问题 #19）。
• 解析器不支持过时的电子邮件格式。因此，如果您需要识别2008年之前就已被废弃的格式，仅解析传入的电子邮件是不够的。

计划（尚未实现）

• 支持内容传输编码（通过Quoted Printable或Base64或其它方式处理unicode）
• 支持其他RFC定义的电子邮件头
  • 支持RFC 6854（更新了From和Sender语法）
  • 支持IANA注册的所有头（http://www.iana.org/assignments/message-headers/message-headers.xhtml）
• 使用mime_multipart支持MIME（RFC 2045、RFC 4021、RFC 2231、RFC 6352）
• 支持从磁盘流式传输MIME部分。

历史

本项目受到早期email crate的启发，但由于设计、实现和接口存在许多重大差异，因此从头开始进行了重构。

许可

许可方式如下

• Apache License，版本2.0，（LICENSE-APACHE或http://www.apache.org/licenses/LICENSE-2.0）
• MIT许可（LICENSE-MIT或http://opensource.org/licenses/MIT）

由您选择。

贡献

除非您明确说明，否则根据Apache-2.0许可定义的任何有意提交以包含在您的工作中的贡献，都将如上双重许可，没有任何额外的条款或条件。