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
