On Sat, Jan 18, 2020 at 02:54:27PM +0100, Alex Woick wrote: > 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.
Wrote a patch for spamass-milter as per the bug.. took much more time than I wanted, ugh. Someone else can harass maintainers/distros to update it now. :-)
