Charles Lindsey wrote:
On Mon, 23 May 2011 03:50:06 +0100, Hector Santos
<hsantos(_at_)isdg(_dot_)net> wrote:
It would of been nice to have some DKIM-Signature flag that might
indicate the Content-Transfer-Encoding, i.e.:
et="base64" <--- copy of the top level Content-Transfer-Encoding
Could you get the effect of this by including the
Content-Transfer-Encoding header in the 'h=' and doing some fancy checks
involving the 'bh=' (to detect whether it was the body or the headers or
both that were broken)?
Using the currently defined standard specification, the only way to do
a reliable check is to add the z= header which contains the values of
the h= header fields. However, having z= is more for testing, can be
exploited in some fashion and adds ugly DKIM-Signature bandwidth
overhead. So its not a good idea, I think, for everyday usage.
But since DKIM is "flexible" :), adding maybe an et= tag should not
break the system allowing for exploration to see if that could help
lower failures for some streams.
In this test case with the gmail.com message submitted to a non-DKIM
aware list, it would of succeeded knowing the original top level
encoding type and using l= if destined to a list.
I think the other side point in my OP, is that it didn't seem it was
necessary to base64 the message content. I saw no 8 bit characters
when I decoded it - just plain 7bit ascii. So it seems some systems
are always doing it regarding of 7/8 bit.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html