----- Original Message -----
From: "Michael Thomas" <mike(_at_)mtcc(_dot_)com>
Is this correct?
Yes, that's correct.
In my technical opinion, we need to do as much as we can to stream line
protocol. The system parsing requirements is already complex as it is.
There is would be no harm in mandating a final tag "b=" location. I
it should be a *rule* for the b= signature tag to be the last tag added
the DKIM-Signature: record.
I really don't see that it's necessary -- I hadn't tested it, but my
code just nuked the value of the b= and kept on going. It didn't have
to do anything special depending on its position. The trailing semicolon
*is* syntactically valid, so your parser needs to be robust for that
even if b= is the last value.
Every software needs to be robust, so that isn't the issue. :-)
The point was that it is only logical to be the last tag. Why would it be
I could only see this being done during the signing process, if during the
course of parsing the message, the coder prepares a DKIM-Signature string
with a "b=;" tag before it adds the other tags that must be part of the
But that makes the coding more complex to "insert" the signature, when in
fact, by not embedding the tag, all that needs to be done in the end is to
concatenate the final ";\r\nb=signature;" string.
We are talking standard intrinsic string logic versus "more coding"
requirement to perform an insert or string replacement.
Oh sure, if you are using a C/C++ string API that would be a piece of cake,
of course. Either way, it just needs to be mentioned that this is possible
if this is going to the case.
I don't care either way, this is a small item once the logic is spelled out,
but I do think it will make the specification coding much more logical by
keeping the signature as the last tag. IMTO.
Hector Santos, Santronics Software, Inc.