MBOX-Line: From lyndon at orthanc.ca  Fri Jul  9 20:28:08 2010
To: imap-protocol@u.washington.edu
From: Lyndon Nerenberg <lyndon@orthanc.ca>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] folding/encoding of subject in ENVELOPE
In-Reply-To: <0D64214F-14CE-43EB-AFC8-9E00DE63EC7F@iki.fi>
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>
	<0D64214F-14CE-43EB-AFC8-9E00DE63EC7F@iki.fi>
Message-ID: <alpine.BSF.2.00.1007092022330.49338@legolas.orthanc.ca>

> But it's not just the line folding. All LWSP containing tabs, spaces and 
> CRLFs are converted into a single space by many servers (IIRC also 
> UW-IMAP). RFC 822 says that all LWSP is equivalent to a single space in 
> structured fields, but subject is unstructured field.

It's tricky dealing with the mapping from *822 to IMAP envelope when faced 
with CRLF. For structured fields you can collapse according to FWS and 
punt. For the others the mapping is undefined. (Well, they're all 
undefined for that matter.)

It's a safe bet that IMAP clients aren't going to deal well with ENVELOPE 
fields that contain line breaks, so I think it's reasonable to replace 
CRLF with SP in an ENVELOPE response. For the places where the visual 
presentation of a line break really matters, the client will not be 
parsing the content anyway (i.e. the Fetch pass-thru).

--lyndon

