RE: Results returned by Opendkim in email header

> -----Original Message-----
> From: opendkim-users-bounce_at_lists.opendkim.org [mailto:opendkim-users-bounce_at_lists.opendkim.org] On Behalf Of Mark Martinec
> Sent: Tuesday, March 01, 2011 10:25 AM
> To: opendkim-users_at_lists.opendkim.org
> Subject: Re: Results returned by Opendkim in email header
>
> [...]
>
> The RFC 6008 doesn't say anything about a possibility of adding FWS into
> the header.b . According to RFC 5451 one could use a quoted-string for
> this purpose which may embed FWS, but there is no semantic note
> saying that such FWS in a quoted-string of header.b could be ignored.
>
> So, is this a specification problem, or an implementational one?

Overall I'd call it a specification problem. Feel free to open an errata item via the RFC Editor page, and when it comes time to update RFC6008, this can be included there.

But there's also the fact that "header.b" is supposed to contain part (or all) of a "b=" value, and from that one could infer the semantics of the "b=" tag from RFC4871, which does say internal whitespace is to be discarded.

It might also be a good optimization for libopendkim to disregard two signatures that are clearly identical. If you agree, please open a feature request on SourceForge.

> Btw, it would be nice if RFC 5451 would mandate or at least recommend
> that the A-R subfields or separate A-R header fields regarding DK/DKIM
> signatures should follow the order of signatures in a mail header section.
> The A-R is already declared a trace field, so adding a word on its
> internal order would even eliminate the need for RFC 6008.

The reason header.b was added is because there are some MTAs that reorder header fields, against what the RFCs say. What you're suggesting would require that if that's done, such an MTA also would need to reorder A-R fields or their components to match, and I didn't think that was likely to be successful (and, in fact, RFC5451 forbids alteration of existing A-R fields).

That said, it probably doesn't hurt to make such a recommendation, with the reordering caveat also mentioned. You could add an errata item for RFC5451 covering that as well.

-MSK
Received on Wed Mar 02 2011 - 00:59:12 PST