On Jul 20, 2006, at 7:58 AM, Barry Leiba wrote:
I have seen a combination of references to 822 and 2822 in recent
discussions on the list. Is the requirement that DKIM support
both 822/2822 content (822 being the current standard) or is the
intent that DKIM is just required to support 2822 content?
I believe there are two parts to the answer to that:
1. We refer to RFC 282x, as the current standard, and that's what
we're aiming to support.
2. We're trying, to the extent we reasonably can, to deal with most
of what's actually out there, which includes RFC-82x-compliant
stuff as well as some small subset of odd or "broken" behaviour
that we consider to be common enough to be worth working with.
Does anyone think that's not the right answer?
RFC822 does not offer assurances with respect to header ordering,
however there is not much caution included in this regard.
This note however which seems to suggest that RFC822 is viewed as
anti-social:
INFORMATIVE ADMONITION: Despite the fact that [RFC2822] permits
header fields to be reordered (with the exception of Received
header fields), reordering of signed header fields with multiple
instances by intermediate MTAs will cause DKIM signatures to be
broken; such anti-social behavior should be avoided.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html