Henrik K schrieb am 18.01.2020 um 08:15:
On Sat, Jan 18, 2020 at 06:56:53AM +0200, Henrik K wrote:
On Tue, Jan 14, 2020 at 02:38:06PM +0100, Alex Woick wrote:
Link to complete message:
[2]https://pastebin.com/raw/1DLtnuRX
Spamassassin is running as spamc/spamd, and is embedded in Postfix with
spamass-milter. System is running on CentOS 7.
...
Any idea how to find out why Spamassassin isn't able to successfully verify
dkim sigs, while at the same time Opendkim says it's valid? I just activated
the dkim plugin of Spamassassin but didn't configure anything dkim-related,
since there is nothing specific to do.
Naturally first step to debug this, would be enabling debugging.
Does SA fail if you run it from command line?
spamassassin -t -D dkim < message
If not, then add the same "-D dkim" to spamd, probably
/etc/sysconfig/spamassassin if using CentOS package?
Actually I already found the cause, spamass-milter is removing CR from
wrapped headers, and some 3.4.3 changes made things break. I'm not sure
about the fix, I need some more eyes on the bug below please. :-)
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7785
Thanks for picking this up as bug. As far as I know, dkim signature
generation takes a header as it is, regardless of the header being
rfc-compliant or not. So if a line wrapping is LF only, and even if this
is not rfc-5322-compliant, it must be fed this way into the dkim
signature generation and verification.
An issue is probably, that you may need 2 versions of wrapped headers.
One with the original, possbly non-rfc compliant data for processing
with modules like dkim, and one with "fixed" data to allow normalized
and easier rule processing.
Alex
