MBOX-Line: From bill.shannon at ymail.com  Tue Oct 30 15:43:49 2012
To: imap-protocol@u.washington.edu
From: Bill Shannon <bill.shannon@ymail.com>
Date: Fri Jun  8 12:34:49 2018
Subject: [Imap-protocol] Re: significance of leading whitespace in RFC 2822
	unstructured headers
In-Reply-To: <BE7CF18C-D8A6-4509-882E-BBA74FC707F3@oracle.com>
References: <508F017B.4000606@ymail.com>
	<CAC4RtVAbtsg38HstaFYO8Hv4H6-X7noeMNRey1DtkvYEbrOQyA@mail.gmail.com>
	<508F4486.8060405@ymail.com>
	<BE7CF18C-D8A6-4509-882E-BBA74FC707F3@oracle.com>
Message-ID: <50905825.3000709@ymail.com>

Joe Pallas wrote on 10/30/12 10:09:
> 
> On Oct 29, 2012, at 8:07 PM, Bill Shannon wrote:
> 
>> One of the reasons I asked here is because of the interaction between
>> the syntax of these header fields and what an IMAP server should do
>> when parsing the header and returning the parsed value.
> 
> I would say that you are probably right that servers are not actually obeying the spec but it?s hard to see that it matters.  If I ask an IMAP server to fetch ?BODY[HEADER.FIELDS (Subject)]? I don?t get back a parsed value, I get back the entire subject line, including any white space between the colon and the first non-WS character.
> 
> The two occasions I can think of where skipping white space in an unstructured header might matter are:
> 1) ENVELOPE, which contains the subject string, and
> 2) SEARCH of the subject string
> 
> It appears that many servers will elide leading spaces from the subject in the returned ENVELOPE structure.  It also appears that some servers will ignore leading spaces in search strings.  At least one server does the former but not the latter.
> 
> I can?t imagine relying on the server?s parsing for something like a digital signature.  Unless the server is actually modifying the message headers returned by a non-ENVELOPE fetch, though, I don?t think this should be a concern.

Yes, you can always ask for the raw header line and parse it yourself if the
difference matters to you.  I think the mistake was writing a digital
signature spec that depended on the difference, rather than canonicalizing
the data first.  We could argue whether such canonicalization should include
just stripping leading and trailing whitespace, or should also include
converting any sequences of whitespace to a single space character.

It would also be nice if the IMAP spec indicated that these fields are
canonicalized in some (perhaps undefined) way, although without agreeing
on the canonicalization algorithm you still couldn't rely on the data when
computing a digital signature.

