[Fwd: Re: [ietf-dkim] canonicalized null body and dkim]

[Stephen Farrell]

Ok, so we've this and we've that. Who's volunteering to
craft new text for the document?

S.

Michael Thomas wrote:
> Tony Hansen wrote:
>> Michael Thomas wrote:
>>  
>>> Tony Hansen wrote:
>>>    
>>>> That's why the issue was raised.
>>>>
>>>> I firmly believe that we *intended* to canonicalize each of these
>>>> cases into the empty body
>>>>
>>>>       
>>> Well, that may or may not have been the intent, but the current spec
>>> does say that and it's my claim that what the current spec is doing
>>> is *useful* given the mangling that happens in the infrastructure.
>>> That is, we're getting better pass rates when we implement the spec
>>> as it is written now.
>>>     
>>
>> Ah, but several of us are convinced that the current spec does *not* say
>> that and we want a clarification added one way or the other.
>>
>> There's no one disputing that the current spec isn't useful.
>>
>> If I read your message correctly, your implementation implements
>> canonicalizing a body with nothing but CRLFs into an empty body. Or is
>> there a missing "not" in your statement and I'm wrong?
>>   
> 
> My previous implementation did the same as Arvel's (given his recent
> mail), which is the same thing that I think that Murray's  is doing. But
> to be pedantic:
> 
> null body:
> 
> Last-header: foo<crlf>
> <crlf>
> 
> l=2; canon-body: <crlf>
> 
> single crlf:
> 
> Last-header: foo<crlf>
> <crlf>
> <crlf>
> 
> l=2; canon-body: <crlf>
> 
> two trailing crlf's
> 
> Last-header: foo<crlf>
> <crlf>
> <crlf>
> <crlf>
> 
> l=2; canon-body: <crlf>
>> *My* implementation does so. Arvel's does so.
>>
>> But another implementation I know of changes it into a CRLF. Sigh. So we
>> are NOT currently getting compatible implementations with the current
>> wording.
>>   
> 
> Right. That was my reason to bring this up.
>> Back to intents: I believe the intent of the extra CRLF rule was to
>> handle transport modifications to the body that added an extra CRLF to
>> the end of the message. This was considered such a common modification
>> that we wanted to reduce the affects of it even in the simple
>> canonicalization mechanism.
>>   
> 
> Note that as I read the current draft, it also allows for the _removal_ of
> trailing CRLF's too. Which is what I've seen in the field too. Note that
> this isn't even a controversial point except for the question of null 
> bodies,
> but the draft seemingly covers that too with its null rule, though it's not
> very clear.
> 
>       Mike
>> Adding such an extra CRLF during transport could generate any of these
>> cases:
>>
>> Last-header: foobarCRLF
>> CRLF
>>
>> Last-header: foobarCRLF
>> CRLF
>> CRLF
>>
>> Last-header: foobarCRLF
>> CRLF
>> CRLF
>> CRLF
>>
>> and they MUST be treated identically because you can't tell which of
>> those CRLFs were original and which were added later.
>>
>> So, I believe that the intent was: 1) to strip out all trailing CRLFs.
>> 2) If there *is* body content other than those CRLFs, the last
>> non-CRLF-only line would be guaranteed to have a CRLF at its end.
>>
>> And 3.4.3 needs to be adjusted to guarantee that intent.
>>
>>     Tony Hansen
>>     tony at att.com
>>   
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
>