Charles Lindsey wrote: > On Mon, 23 May 2011 03:50:06 +0100, Hector Santos <hsan...@isdg.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
