33 lines
1.3 KiB
Plaintext
33 lines
1.3 KiB
Plaintext
MBOX-Line: From bill.shannon at sun.com Fri Jul 9 18:06:09 2010
|
|
To: imap-protocol@u.washington.edu
|
|
From: Bill Shannon <bill.shannon@sun.com>
|
|
Date: Fri Jun 8 12:34:45 2018
|
|
Subject: [Imap-protocol] folding/encoding of subject in ENVELOPE
|
|
Message-ID: <4C37C781.5060700@sun.com>
|
|
|
|
I sent this once a few days ago, but it's not showing up in the archives, so...
|
|
|
|
Just to make sure I'm interpreting it correctly...
|
|
|
|
The spec says:
|
|
|
|
ENVELOPE
|
|
A parenthesized list that describes the envelope structure of a
|
|
message. This is computed by the server by parsing the
|
|
[RFC-2822] header into the component parts, defaulting various
|
|
fields as necessary.
|
|
|
|
The fields of the envelope structure are in the following
|
|
order: date, subject, from, sender, reply-to, to, cc, bcc,
|
|
in-reply-to, and message-id. The date, subject, in-reply-to,
|
|
and message-id fields are strings.
|
|
|
|
The subject field may include MIME encoded words (because the IMAP protocol
|
|
is ASCII) and may contain CRLF as a result of line folding in the original
|
|
MIME header (because the subject field may be a literal that may contain
|
|
CRLF), correct?
|
|
|
|
The phrase "parsing the header into component parts" isn't meant to suggest
|
|
that the server must remove any of these artifacts from the subject, right?
|
|
|