Re: opendkim body hash did not verify problem

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Sat, 24 Apr 2010 21:16:34 -0700 (PDT)

On Sat, 24 Apr 2010, Rolf E. Sonneveld wrote:
> 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.

Interesting observation. I wonder if this was ever pointed out to the
DKIM working group. I'll do so myself shortly. I expect, though, that
the response will be that DKIM operates at a level nearer to the transport
than the interpretation of the header fields, so it's not really DKIM's
concern to be accomodating here. That is, the "matching" to which RFC2045
refers is a semantic matter, which is above the level at which DKIM
operates.

Also, I would bet real money that changing courier is going to be a whole
lot easier in the short term than changing a published standards track
RFC.

As SM points out, OpenDKIM could accomodate this either in the library or
in the filter, but then again I don't want it to become a repository of
hacks to accomodate issues with various other software packages if that
can be avoided.

-MSK
Received on Sun Apr 25 2010 - 04:16:54 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:19:47 PST