Forum Discussion
Microsoft's e-mailservers break DKIM on non-ascii characters
There seems to be some kind of character encoding issue in DKIM signatures applied by Office365 servers. We just had a DKIM fail ('body hash did not verify') and tracked it down to non-ascii quotes b...
Since you mention Content-Transfer-Encoding... I also observe in my case that the message lands in gmail with Content-Transfer-Encoding: 8bit, while in outlook (where dkim fails to verify body hash), it gets "quoted-printable". I am investigating if the code generating the message specifies Content-Transfer-Encoding in header.
So we sat Content-Transfer-Encoding: 8bit on the email generating app. The message got delivered to outlook inbox with Content-Transfer-Encoding: 8bit. But.. charset still got changed to "iso-8859-1". While the generating code specifies UTF8. DKIM body hash verificaton still failing, of course.
I am working with support of the cloudy mta provider, my suspicion is that the charset change (aka the reason for DKIM fail) occurs at the cloudy mta.
Just got confirmation from cloudy MTA support that it is they who switch encoding from UTF8 to iso-8859-1 because of non-ascii characters in the body.
- Still, it's Microsoft's servers that add the body hash, and I think it's a bug that with injecting certain bytes, you can break that. In-band bytes should not affect the protocol.
- no.
