https://bugs.exim.org/show_bug.cgi?id=2016
--- Comment #2 from Ivo Truxa <truxa@???> ---
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.
