Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refine and document Envelope fields #31

Open
jonhoo opened this issue Nov 22, 2018 · 4 comments
Open

Refine and document Envelope fields #31

jonhoo opened this issue Nov 22, 2018 · 4 comments

Comments

@jonhoo
Copy link
Contributor

jonhoo commented Nov 22, 2018

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
Copy link
Owner

djc commented Nov 23, 2018

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
Copy link
Contributor Author

jonhoo commented Nov 23, 2018

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
Copy link
Contributor Author

jonhoo commented Dec 7, 2018

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

@djc
Copy link
Owner

djc commented Dec 7, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants