> >Someone on the opendkim-users list has pointed out that DKIM
> >signatures are being invalidated when re-mailed through one
> >particular MLM that rewrites Content-Type: so that its value is all
> >lowercase. Obviously this is a problem for DKIM since even "relaxed"
> >requires nothing other than spacing changes in header field values;
> >however RFC2045 says that the interpretation of Content-Type: values
> >is case-insensitive. Thus, at least to consumers of that header
> >field, DKIM is doing something "wrong". In any case, it was
> >suggested on that list that "relaxed" header canonicalization be
> >adjusted to accommodate this.
> Although I see the point in this particular case, it seems to me that
> it would be a hopeless rathole to try to catalog and account for all
> of the semantics of every possible header line and the set of possible
> modifications to each header that do or do not make a semantic
> difference. Looking at the RFCs, I can't tell whether the boundary
> string in Content-Type: is supposed to be case sensitive, but the
> addresses in To:, From:, Cc;, and so forth certainly are, and I
> wouldn't want to get into an argument about whether the Subject: line
> is.
It's a hopeless rathole for a variety of reasos, but boundary parameters aren't
one of those reasons.
Boundary parameters are case sensitive. This is explicitly stated in
RFC 2045 section 5.1 and probably in other places as well.
More generally, media type parameters default to case sensitive; however, many
definitiosn override this default either explicitly (e.g., charset) or
implicitly (e.g., version parameters whose syntax only allows numbers and
punctuation).
But since new media types are defined all the time, and old ones are revised,
to say nothing of the types people just make up and never register. As such,
you cannot possibly code something that gets case normalization right in
general. So yes, it's hopeless.
Ned
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
