So it's wasn't line breaks afterall.
It turned out that OpenSMTPD passes raw SMTP data lines to filters and
raw SMTP lines have leading dot characters escaped by another dot, so
.text became ..text. Feeding it to Rspamd like that made DKIM alignment
tests fail, because body hash came out wrong.
A pull request has been submitted with a fix.
This how seems to be a problem with Rspamd:
arc=reject (signature check failed: fail, {[1] = sig:google.com:reject});
Good luck,
Reio
On 13.10.2019 17:43, Reio Remma wrote:
Things seem to have gotten worse on Google Groups front though:
ARC-Authentication-Results: i=3;
orc.mrstuudio.ee;
dkim=pass header.d=googlegroups.com header.s=20161025 header.b=HBqGik0B;
dkim=pass header.d=gmail.com header.s=20161025 header.b=PGhHBIgC;
arc=reject (signature check failed: fail, {[1] =
sig:google.com:reject});
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (orc.mrstuudio.ee: domain [email protected]
designates 209.85.215.186 as permitted
sender)[email protected]
Authentication-Results: orc.mrstuudio.ee;
dkim=pass header.d=googlegroups.com header.s=20161025 header.b=HBqGik0B;
dkim=pass header.d=gmail.com header.s=20161025 header.b=PGhHBIgC;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (orc.mrstuudio.ee: domain [email protected]
designates 209.85.215.186 as permitted
sender)[email protected]
---
ARC-Authentication-Results: i=3;
orc.mrstuudio.ee;
dkim=fail (body hash did not verify) header.d=googlegroups.com
header.s=20161025 header.b=Q/j34gd1;
dkim=fail (body hash did not verify) header.d=gmail.com
header.s=20161025 header.b=pPw7LbVC;
spf=pass (orc.mrstuudio.ee: domain [email protected]
designates 209.85.222.184 as permitted
sender)[email protected];
arc=reject (signature check failed: fail, {[1] = sig:google.com:reject})
Authentication-Results: orc.mrstuudio.ee;
dkim=fail (body hash did not verify) header.d=googlegroups.com
header.s=20161025 header.b=Q/j34gd1;
dkim=fail (body hash did not verify) header.d=gmail.com
header.s=20161025 header.b=pPw7LbVC;
dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com
(policy=none);
spf=pass (orc.mrstuudio.ee: domain [email protected]
designates 209.85.222.184 as permitted
sender)[email protected]
On 13.10.2019 16:37, Reio Remma wrote:
So far there's a marked improvement!
Waiting for a FB notification now - asked the wife to message me. :P
Authentication-Results: host.domain.com;
dkim=fail (body hash did not verify) header.d=gmail.com
header.s=20161025 header.b=SLB9Imr3;
dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com
(policy=none);
spf=pass (host.domain.com: domain [email protected] designates
45.76.46.201 as permitted sender)[email protected]
Authentication-Results: host.domain.com;
dkim=pass header.d=gmail.com header.s=20161025 header.b=ot9QqpYS;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (host.domain.com: domain [email protected] designates
45.76.46.201 as permitted sender)[email protected]
---
Authentication-Results: host.domain.com;
dkim=fail (body hash did not verify) header.d=gmail.com
header.s=20161025 header.b=SLB9Imr3;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (host.domain.com: domain [email protected] designates
209.85.128.45 as permitted sender)[email protected]
Authentication-Results: host.domain.com;
dkim=pass header.d=gmail.com header.s=20161025 header.b=ot9QqpYS;
dmarc=pass (policy=none) header.from=gmail.com;
spf=pass (host.domain.com: domain [email protected] designates
209.85.128.42 as permitted sender)[email protected]
On 13.10.2019 16:27, Reio Remma wrote:
Just restarted my daemon with the modified filter. :)
Will have to get someone message me at FB now.
On 13.10.2019 16:22, Gilles Chehade wrote:
Very likely yes, can you give it a try ?
On Sun, Oct 13, 2019, 15:15 Reio Remma <[email protected]
<mailto:[email protected]>> wrote:
On 13.10.2019 16:09, Reio Remma wrote:
On 13.10.2019 16:05, Gilles Chehade wrote:
I don't think that is the issue, it is probably the
filter-rspamd reconstruction of the message that is incorrect.
I was thinking along the same lines, but I'm not sure how
OpenSMTPD splits strings before passing them to the filter.
Can the filter then extract "leftover" line endings for
incoming strings and make decision based on that when joining
the strings before Rspamd?
Do you experience the same yourself?
strings.NewReader(strings.Join(s.tx.message, "\n"))
Wonder if we should use \r\n here?
Reio
On Sun, Oct 13, 2019, 15:00 Martijn van Duren
<[email protected]
<mailto:[email protected]>> wrote:
On 10/13/19 1:59 PM, Reio Remma wrote:
> Hello!
>
> I finally moved to Rspamd (2.0) on my production server
and I'm seeing
> lots of failed DKIM checks, specifically dkim=fail
(body hash did not
> verify).
>
>
> Authentication-Results: host.domain.com
<http://host.domain.com>;
> dkim=fail (body hash did not verify)
header.d=facebookmail.com <http://facebookmail.com>
> header.s=s1024-2013-q3 header.b=pNWbKJUd;
> dmarc=pass (policy=reject)
header.from=facebookmail.com <http://facebookmail.com>;
> spf=pass (host.domain.com
<http://host.domain.com>: domain of
[email protected]
<mailto:[email protected]>
> designates 66.220.144.215 as permitted sender)
> [email protected]
<mailto:[email protected]>
>
> My current stab-in-the-dark theory is that there might
be something
> going on with line endings when mails are fed to Rspamd.
>
> Any better theories? :)
It's a known issue that mails that don't end on \r\n
(both \r\r\n and
\n) cause issues. There's efforts going on to see how we
can remedy
this, but in the mean time tell your senders that they
should fix their
mails (RFC5321):
In addition, the appearance of "bare" "CR" or "LF"
characters in text
(i.e., either without the other) has a long history of
causing
problems in mail implementations and applications that
use the mail
system as a tool. SMTP client implementations MUST
NOT transmit
these characters except when they are intended as line
terminators
and then MUST, as indicated above, transmit them only
as a <CRLF>
sequence.
>
