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