mailing list archives

(Maybe there's an RFC 2822 experts list that would be more appropriate
for this question?  If so, please point me in the right direction.)

According to the RFC 2822 syntax, any whitespace after the colon in
an unstructured header is part of the value of that header.
This means that in the header

Subject: test

The value of the subject header is " test" with a leading space.

I suspect the UW IMAP server is not alone in returning "test" as the
subject for such a message.

Similarly for the Content-Description header.

(A quick test shows that the UW IMAP server preserves trailing whitespace
but not leading whitespace in Subject and Content-Description headers.)

Am I misinterpreting the RFC 2822 spec?  I'd really like that leading whitespace
to be insignificant, and I suspect that's the way most people and software
treat it, but I can't see where the spec says that.

This is an issue because an OASIS security spec says that all whitespace
in unstructured headers must be preserved, and factors into the digital
signature of the message.

Thanks.

> (Maybe there's an RFC 2822 experts list that would be more appropriate
> for this question?  If so, please point me in the right direction.)

Two things, to start with:

1. The right list for this would be ietf-822@ietf.org

2. RFC 5322 is the current spec; 2822 is obsolete.

Barry

Barry Leiba wrote on 10/29/2012 05:41 PM:
>> (Maybe there's an RFC 2822 experts list that would be more appropriate
>> for this question?  If so, please point me in the right direction.)
> 
> Two things, to start with:
> 
> 1. The right list for this would be ietf-822@ietf.org

Thanks for the pointer.  I'll ask there if no answer appears here.

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.  The syntax
would imply that all whitespace after the colon is part of the value
of the header, but that's not what most/all IMAP servers do, and not
what the examples show.  Is there something in the IMAP spec that
says leading whitespace should be removed from these header values?

> 2. RFC 5322 is the current spec; 2822 is obsolete.

A quick scan didn't turn up anything that would resolve my issue
differently.

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.

joe

On 30.10.2012, at 5.07, 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.  The syntax
> would imply that all whitespace after the colon is part of the value
> of the header, but that's not what most/all IMAP servers do, and not
> what the examples show.  Is there something in the IMAP spec that
> says leading whitespace should be removed from these header values?


http://marc.info/?t=105363818800005&r=1&w=4

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.