Eric Allman wrote:
Well, this is unfortunate, and I'm not sure how we ended up with both
FWS and LWSP at the same time. As Frank noted they are nearly equivalent.
The problem is that both of them are assuming use in a header field
context, which requires the trailing white space. Contrary to what
Frank says, just replacing LWSP with [FWS] won't solve the problem. In
fact, since base64string is used both in the DKIM-Signature header field
and in the selector record, we would need to split that in two. Ugly.
For the time being I agree with Paul's suggestion: live with it. This is
the sort of thing that can be solved in DKIMbis, which I'm sure will be
required before DKIM gets to full standard.
This seems like a perfect reason why Postel's Rule still applies:
putting whitespace in a base64 string is just asking for trouble
in the key record, but a good receiver should be tolerant regardless
of the letter of the spec since it doesn't change the underlying
semantics.
As Eric alludes to, this is exactly why there's PS --> DS to clean
these kinds of niggling things up; if this is the only ABNF goof,
we'd be doing pretty well.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html