mikedilger/email-format

Email data structure and builder for streaming emails

email-format's Issues

RFC 4021 registered header fields

Recognition of parsing/format of RFC 4021 registered header fields

RFC 6477 MMHS headers

Full character sets in body and headers

Add support for

Parsing a RFC2822 date from Chrono

Chrono's to_rfc2822 method will return a date string like the following:

Fri,  8 Sep 2017 20:46:39 +0000

This is unparseable by email-format, seemingly because the single digit (8) for the day-of-month:

thread 'main' panicked at 'called Result::unwrap() on an Err value: "DateTime" Not Found', src\libcore\result.rs:906:4

I've been reading RFC2822, and do be honest I can't tell if a single-digit field is allowed. Do you think this is a email-format parsing problem? Or a Chrono formatting problem?

Use semantic chunks in API, not ABNF chunks

The ABNF chunks defined in RFC5322 do not match exactly to the semantic chunks. For instance, message-id is defined with angle brackets in the ABNF, but the text of the standard indicates that angle brackets are not part of the semantic meaning of message-id. Therefore, set_message_id() ought to not require angle brackets, but parsing/streaming ought to handle them appropriately.

It gets weirder with whitespace. You might think whitespace following the colon after a header name belongs to the label somehow, but no, it belongs to the next token in the ABNF, defined as allowed via multiple ABNF constructions, the net result is that it just so happens to be allowed after every header name and colon. However, the whitespace is semantically not part of most tokens that allow it. How do we parse out and put in whitespace in a consistent manner, and not require callers to add whitespace to the token when they want a space after the colon (e.g. with set_sender(" a@b"))?

The changes implied here will likely break existing code, and potentially will be very extensive.

improve errors generated

A generic ParseError is not sufficient for informing users why their email is invalid.

In most cases a NotFound variant gives too little information.

further on Email struct with getters and setters

This has been in development on the master/dev branches, and will be available soon.

Support for custom headers?

I'd like to use this crate in my application and am missing one crucial feature. I want to add custom headers to the email struct I create and then save it to disk.

I did not see anything in the documentation that allows custom / arbitrary email headers to be added to the email. Could you please implement this feature?

Header strategy - Enum, Trait objects, etc

I tried doing trait objects. It did not turn out well. The trait wants a "stream_out" function which must be type parameterized. However, trait objects in rust must not have such functions for object safety reasons.

Currently the 'dev' branch code uses fields, one per header type, but this is tedious.

I'm leaning towards enums...

pub enum Header {
  OrigDate(DateTime<FixedOffset>),
  To(String),
  // ...etc
}
impl Header {
  pub fn name(&self) -> &'static str {
    match *self {
      OrigDate(_) => "Date",
      To(_) => "To",
      // ...etc
    }
  }
  pub fn multiple(&self) -> bool {
    // ...
  }
}

pub struct Email {
  single_headers: HashMap<&'static str, Header>,
  multiple_headers: HashMap<&'static str, Vec<Header>>,
  // ...etc
}

Verify/fix visibility

I think some structs are visible, but they have pub fields of types which are not visible.

Use chrono for time types

Hey, this is currently the best mail parser crate I have found!

It would be great if the create used chrono for date/time types though, since it is pretty much the standard in the ecosystem.

Implement resent headers

RFC 6854 updates

Some fields defined in rfc 5322 are updated in rfc 6854.

Errata 3135, quoted string ABNF

Adjust/fix for:
RFC Errata ID 3135
quoted-string = [CFWS]
DQUOTE ((1*([FWS] qcontent) [FWS]) / FWS) DQUOTE
[CFWS]

RFC 6857 (obs 5504, others) re Downgraded headers

Some of the "Downgraded" headers are still standardized, according to
http://www.iana.org/assignments/message-headers/message-headers.xhtml

Downgraded-Final-Recipient mail standard [RFC6857 Section 3.1.10]
Downgraded-In-Reply-To mail standard [RFC6857 Section 3.1.10]
Downgraded-Message-Id mail standard [RFC6857 Section 3.1.10]
Downgraded-Original-Recipient mail standard [RFC6857 Section 3.1.10]
Downgraded-References mail standard [RFC6857 Section 3.1.10]

Miscellaneous headers

From this list, ignoring headers listed in other issues, we have a number of miscellaneous headers defined in various RFCs. http://www.iana.org/assignments/message-headers/message-headers.xhtml

Body none reserved [RFC6068]
Archived-At mail standard [RFC5064]
Authentication-Results mail standard [RFC7601]
Auto-Submitted mail standard [RFC3834 section 5]
DKIM-Signature mail standard [RFC6376]
MT-Priority mail standard [RFC6758]
Organization mail informational [RFC7681]
Original-From mail standard [RFC5703]
Original-Recipient perm/original-recipient mail standard [RFC3798][RFC5337]
Original-Subject mail standard [RFC5703]
Received-SPF mail standard [RFC7208]
Require-Recipient-Valid-Since mail standard [RFC7293]
Solicitation mail [RFC3865]
VBR-Info mail standard [RFC5518]

Using umlauts

How can I create an eMail with umlauts?
Using them causes InvalidInput, error: Trailing input at byte :(

MIME, RFC 4021 mime-part headers

Parser

Finish the RFC 5322 parser on the 'dev' branch, with tests for each parse function.

Fold if line too long

To avoid lines longer than 998 characters, we should be adding folding white space where available.
We will need a fold method (per header type / enum variant), as different headers have different places where they may be folded.

Impl From for OrigDate from chrono and time structures

done on master.

mime-multipart

RFC 5322 is a good start, but other RFCs extend this. In particular we need to support mime-multipart headers and bodies.