On 23 Sep 2019, at 11:43, Jari Fredriksson wrote:
Bill Cole kirjoitti 23.9.2019 18:26:
On 23 Sep 2019, at 1:00, Jari Fredriksson wrote:
Hello again.
I have a problem that arises after my mail server has been up for
maybe two days. Suddenly all DKIM-verifications in SpamAssassin says
DKIM_INVALID while those look valid to be when looking to mail
source code. It works again correctly after I reboot the machine.
This starter as it is when I upgraded from Debian Stretch to Buster,
I think.
Sample: https://pastebin.com/cZKSTZVC
The signature on that message does not verify according to the
dkimverify.pl from Mail::DKIM or the dkimverify from the Python
'dkimpy' package. Using the --debug-canonicalization option of
dkimverify.pl shows that the 'bh' field matches, so the problem is in
the headers.
In short: it's probably not your problem *in this case*
One side-note on this: In reviewing this I see that the first case is
labeled as multipart/alternative but it contains only an unterminated
text/plain part, so it seems to have been truncated, which is not
consistent with the fact that dkimverify.pl comes up with the same body
hash, so I'm questioning everything now...
All right then. I just received a new mail from Twitter, this time it
has DKIM_VALID_AU. How headers differ?
https://pastebin.com/3p7QiDDj
I don't see anything obvious, but I expect that I wouldn't and that you
wouldn't in the delivered mail. Something in the non-verified message
got changed after signing but the verified message had no such change.
For many months I've been watching a mail system that was having chronic
occasional DKIM failures and writing code to work around and/or prevent
the root causes. This project has not taken so long merely because I'm
bad at coding. The ways that Sendmail in particular can innocently break
signatures are many, so ultimately I resorted to fully parsing existing
address list headers and rebuilding them in a subtly idiosyncratic form
that Sendmail likes.
There's a long-untouched bug report for OpenDKIM (which this system is
not using) due to Sendmail "fixing up" standard address headers. That
fixup is perfectly reasonable UNLESS you're signing them with a milter
ahead of the fixup. Or in your case: unless Twitter is signing them with
a milter before their Sendmail "fixes" headers.
--
Bill Cole