https://bugs.exim.org/show_bug.cgi?id=2016
--- Comment #2 from Ivo Truxa <[email protected]> --- I found the problem When debugging with "exim -d-all+acl -bh <IP>", I did not find a way to get rid of the SMTP data terminating dot, which Exim always includes into the body hash in -bh mode. In result, DKIM body hash never matches in -bh mode - both at saved messages that arrived with good and failed DKIM. However, when crosschecked with shell sha256 and with Perl Mail:DKIM:Verify, after appedning the dot to the data too, I could confirm that the hashes are identical to those of Exim. That means that both the hashing algorithm and the canonalization are working properly in Exim. Therefore, I decided to debug in daemon mode, and there it is where I could see the problem. It is caused by BDAT (https://tools.ietf.org/html/rfc1830). Gmail uses CHUNKING, and the BDAT command sent after each chunk of data (around 63kB in Goggle's case), the command gets inserted into the canonalized string. The data stream remains clean, so the attachments remain intact. It only influences the canonalizing buffer string. I think you do not need my configuration or logs. You can easily reproduce the problem by sending yourself an email from Gmail, containing a binary file over 65kB. When you run Exim in daemon mode with debugging output redirected to a file, you'll see the string "BDAT 34182 LAST" after some 63kB of data (the number may differ). You'll spot it easily, since it mostly breaks down the otherwise uniform data column of the base64 data. An example from my debug file is below: voFq5zaCir2h86qtRTxOujxMvOuRqDGUaQpgDYEwF5nU1fFOXrrMYpdl21qXgH05XPqZ8S5lK1fM^M hhkmDssWITGWTtqIY0bEHhVmGSJZK3pOeRpbsB1KtTStnu+deo1jx9As9FG6JnZ3x7K+AuxfO9jV^M LCads43D9v5gkfjC9Nwa1mvmns8h9IL/AC2pp8vb69M8IICAgICAgICAgICAgICAgICAgICAgICA^M gIMKPittVME7BBKgSFIkjdRgSAmBITsJkyFAgydkkhLCBtBDAT 34182 LAST^M 81B1SCSdkyJBMbiEFplBY7gBBIO6Jh^M fnZRhG6QSVVaFxHVJAAAkjZR2FoBInooEVaradNzydgJKRGR0/nXFRd31QNfIadET9VNU7slMNWD^M BI4IB6qq8LPaNMAb8jsolaHzDvMLhpOkbxChMI8kVfdIEkyES6z8c8J8/LltdeX7lCq6k7fjUNvx^M aufxCjmt5dbhNzluTT5eWbqk61vnsMgA7Ly96l661VlkbYhzgXbwJhcy5S6FqqXN009Y9O60bmYb^M And this is the true data (not canonalized): voFq5zaCir2h86qtRTxOujxMvOuRqDGUaQpgDYEwF5nU1fFOXrrMYpdl21qXgH05XPqZ8S5lK1fM^M hhkmDssWITGWTtqIY0bEHhVmGSJZK3pOeRpbsB1KtTStnu+deo1jx9As9FG6JnZ3x7K+AuxfO9jV^M LCads43D9v5gkfjC9Nwa1mvmns8h9IL/AC2pp8vb69M8IICAgICAgICAgICAgICAgICAgICAgICA^M gIMKPittVME7BBKgSFIkjdRgSAmBITsJkyFAgydkkhLCBt81B1SCSdkyJBMbiEFplBY7gBBIO6Jh^M fnZRhG6QSVVaFxHVJAAAkjZR2FoBInooEVaradNzydgJKRGR0/nXFRd31QNfIadET9VNU7slMNWD^M BI4IB6qq8LPaNMAb8jsolaHzDvMLhpOkbxChMI8kVfdIEkyES6z8c8J8/LltdeX7lCq6k7fjUNvx^M aufxCjmt5dbhNzluTT5eWbqk61vnsMgA7Ly96l661VlkbYhzgXbwJhcy5S6FqqXN009Y9O60bmYb^M I verified with sha256() that Exim indeed calculates the body hash including the BDAT command, which it definitely should not. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
