On Sat, 2020-01-18 at 01:29 +0200, Jari Fredriksson wrote: > On 14.1.2020 15.38, Alex Woick wrote: > > Spamassassin (3.4.3, the same with previous) declares all or almost > > all the incoming DKIM-signed messages as DKIM_INVALID, and I'm not > > understanding why. > > I'm running opendkim on the mail server as milter with Postfix, and > > the opendkim headers say the same dkim signatures are all valid. > > > > Example headers of some mail from this list. > > Opendkim says ok: > > Authentication-Results: mail.wombaz.de; > > dkim=pass (2048-bit key) > > header.d=linkcheck.co.ukheader.i=@linkcheck.co.uk header.b="PXrrNHd > > B" > > > > But Spamassassin says it's invalid: > > X-Spam-Status: No, score=-15.5 required=5.0 > > tests=BAYES_00,DKIM_ADSP_ALL, > > DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS, > > MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_PASS,TXREP > > , > > USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no > > version=3.4.3 > > I had the same problem on my mail server, while the server only 1 Gb > and > was an old box. I swapped it to a 4 Gb box and installed OS and SA > and > all as new install. > > Magically the problem went away. > > One more thing: I got DKIM_VALID & DKIM_VALID_AU allright for a day > after reboot, but it the started to be DKIM_INVALID. I set the mail > server to reboot once a day and it worked. But current system works > fine > without any artificial reboots. > That looks like a combination of:
(a) buffer truncation when memory limits are reached. IOW SA can't get the full buffer size it asked for, and so truncates the message it was putting into the buffer rather than aborting on a buffer overflow. Doing this would certainly screw a checksum. (b) there's some sort of memory leak, i.e. when releasing a dynamically requested piece of memory doesn't return all of it, which could slowly shrink the process's available heap space OR there's code that is failing to return previously claimed heap space. Something like that would explain your second issue, which you got round rebooting the system before SA ran out of heap memory. Both are things you might expect to see in badly written C programs and/or C programs whose testing skimped on edge case testing, particularly when the code uses calls of malloc(), free() and friends to manage dynamic heap memory use. Equally these are things that I would not expect to see in Java code because the JVM has a decent garbage collector and anyway, errors of that are treated as fatal and so would cause program termination with a diagnostic stack dump. However, I'm not familiar enough with Perl to know how it behaves in these circumstances. Still, I hope the above helps with ideas about what to look for. On a UNIX/Linux box 'top' should show the program size expanding over time of stack space isn't being released correctly. I've forgotten how you'd trouble-shoot a Windows system - haven't touched it for over 15 years. Martin