search

djc / tokio-imap

Tokio-based IMAP implementation
Apache License 2.0
123 stars 41 forks source link

Refine and document Envelope fields #31

Open jonhoo opened 6 years ago

jonhoo commented 6 years ago

RFC 3501 section 7.4.2 has a lot to say about envelopes that would be handy to include in the docs for Envelope. Beyond that though, there are some observations there that I think affect Envelope's types. Specifically:

Note: RFC-2822 requires that all messages have a valid Date header. Therefore, the date member in the envelope can not be NIL or the empty string.

Implies that Envelope::date should not be an Option.

Note: [RFC-2822] requires that the In-Reply-To and Message-ID headers, if present, have non-empty content. Therefore, the in-reply-to and message-id members in the envelope can not be the empty string.

Implies the same for Envelope::in_reply_to and Envelope::message_id.

If the Sender or Reply-To lines are absent in the RFC-2822 header, or are present but empty, the server sets the corresponding member of the envelope to be the same value as the from member (the client is not expected to know to do this).

Note: RFC-2822 requires that all messages have a valid From header. Therefore, the from, sender, and reply-to members in the envelope can not be NIL.

Implies the same for Envelope::from, Envelope::sender, and Envelope::reply_to.

djc commented 6 years ago

My reading of the spec is different at least for in_reply_to and message_id. In the paragraph you quote, it says that the relevant headers, if present must have non-empty content, and it continues to state that the envelope members can not be the empty string, but NIL is still allowed here.

As for the others, I worry that servers might not correctly implement some of these things, leading the parser to choke on things that could still usefully be returned to the caller. I'll see if I can check this against my personal mail archive, at least.

jonhoo commented 6 years ago

Ah, yes, I think you're right about in_reply_to and message_id.

Yeah, that's probably a good idea as a sanity check. We could of course implement the fallback inside imap-proto since it's from the spec...

jonhoo commented 5 years ago

@djc did you have a chance to try to run against your mail archive?

djc commented 5 years ago

Nope, not yet -- ran into some problems getting my mailsync code to run with the latest compiler/dependencies and it's been very busy. 😞