45 lines
1.8 KiB
Plaintext
45 lines
1.8 KiB
Plaintext
MBOX-Line: From bill.shannon at sun.com Sun Jul 11 00:57:13 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] Re: folding/encoding of subject in ENVELOPE
|
|
In-Reply-To: <alpine.WNT.2.00.1007091852190.2580@Shimo-Tomobiki.Panda.COM>
|
|
References: <4C37C781.5060700@sun.com>
|
|
<FCB729DF-4574-4EA5-BA6C-B21F5B67B9D1@iki.fi>
|
|
<alpine.BSF.2.00.1007091831130.49338@legolas.orthanc.ca>
|
|
<alpine.WNT.2.00.1007091852190.2580@Shimo-Tomobiki.Panda.COM>
|
|
Message-ID: <4C397959.5090606@sun.com>
|
|
|
|
Mark Crispin wrote on 07/09/2010 08:00 PM:
|
|
> On Fri, 9 Jul 2010, Lyndon Nerenberg wrote:
|
|
>>> Yes, but my server (and many others) are converting all whitespace to a
|
|
>>> single space (tabs, folds, multiple spaces, etc). I can't exactly
|
|
>>> remember why, though. Maybe I implemented it only because others did
|
|
>>> that too..
|
|
>> The '822 <FWS> grammar production.
|
|
>
|
|
> Correct. You interpret the fields as per RFC 822 (etc.).
|
|
>
|
|
> Line folding is an RFC 822 (etc.) concept and is not part of the field
|
|
> data (e.g., Subject). Header fields are logically a single line, even if
|
|
> they are multiple lines in the header.
|
|
>
|
|
> If you think about it and how protocol layering works, it makes sense.
|
|
> You are looking at a message and its fields, not how RFC 822 (etc.)
|
|
> encodes it.
|
|
>
|
|
> Arguably, a future version of IMAP should decode MIME encoded-words into
|
|
> UTF-8.
|
|
|
|
Ok, so now I'm confused.
|
|
|
|
The server is required to interpret and remove some parts of the encoding
|
|
(i.e., folding) but not other parts (MIME encoded words)?
|
|
|
|
I should *never* expect to see a newline in the subject field of the
|
|
ENVELOPE, and if I do that's a bug in the server?
|
|
|
|
Or is unfolding the header something servers are allowed to do but not
|
|
required to do?
|
|
|