Forum Discussion
halfgaar
Oct 13, 2020Copper Contributor
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...
halfgaar
May 07, 2021Copper Contributor
I dove into it a bit more. The mail client is supposed to deliver the content using quoted printable encoding, so only 7 bit ascii (alphanumerics and =). This is the 'Content-Transfer-Encoding', different from the CONTENT encoding, which can still be UTF-8 (in which case ยต will be =C2=B5).
I tried specifying 8 bit as content transfer encoding, but that didn't help.
However, ultimately, the mail client is the original offender, because that apparently just dumps UTF8 bytes into SMTP.
I tried specifying 8 bit as content transfer encoding, but that didn't help.
However, ultimately, the mail client is the original offender, because that apparently just dumps UTF8 bytes into SMTP.
- RNalivaikaMay 10, 2021Iron ContributorSince 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.
- RNalivaikaMay 10, 2021Iron Contributor
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.- RNalivaikaMay 12, 2021Iron Contributor
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.
- halfgaarMay 07, 2021Copper ContributorActually, this is still not it. I tested clients that do proper quoted printable, and it fails. And Postfix +OpenDKIM does handle the above shellscript properly.