tokio-imap icon indicating copy to clipboard operation
tokio-imap copied to clipboard

Refine and document Envelope fields

Open jonhoo opened this issue 5 years ago • 4 comments

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.

jonhoo avatar Nov 22 '18 17:11 jonhoo

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.

djc avatar Nov 23 '18 07:11 djc

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 avatar Nov 23 '18 15:11 jonhoo

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

jonhoo avatar Dec 07 '18 21:12 jonhoo

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

djc avatar Dec 07 '18 21:12 djc