Murray S. Kucherawy wrote:
>> -----Original Message-----
>> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-
>> bounce_at_lists.opendkim.org] On Behalf Of Dino Ciuffetti
>> Sent: Friday, April 23, 2010 4:52 PM
>> To: opendkim-users_at_lists.opendkim.org
>> Subject: RE: opendkim body hash did not verify problem
>>
>>
>> Ok, I found which is the header that create problem in my case.
>> It's Content-Type.
>>
>> [...]
>>
>> The original header coming from gmail.com was:
>> Content-Type: text/plain; charset=ISO-8859-1
>> (Return from dkim_getresultstr(): Success)
>>
>> The courier-mta modified version that fails DKIM verification is:
>> Content-Type: text/plain; charset=iso-8859-1
>> (Return from dkim_getresultstr(): Bad signature)
>>
>> I have found that simply changing the value to uppercase fixed the
>> problem
>> and the verification succeeded.
>>
>> Should relaxed canonicalization tolerate such case modification into
>> the
>> header value or not?
>>
>
> Whatever is rewriting "ISO" to "iso" should be corrected.
>
> Changing the RFC's definition of "relaxed" is a lot of work and would require a lot of people to agree that this is a problem with DKIM itself and not with courier.
>
From RFC2045:
>
> 5.1. Syntax of the Content-Type Header Field
>
>
>
> In the Augmented BNF notation of RFC 822 <http://tools.ietf.org/html/rfc822>, a Content-Type header field
> value is defined as follows:
>
> content := "Content-Type" ":" type "/" subtype
> *(";" parameter)
> ; Matching of media type and subtype
> ; is ALWAYS case-insensitive.
>
So, although IMHO courier should not change the case of the value of the
CT header field, I'd still vote for changing DKIM (if necessary) to have
"relaxed" cover the Content-Type field in line with RFC2045.
/rolf
Received on Sat Apr 24 2010 - 20:59:11 PST