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 of hel...@googlegroups.com 
designates 209.85.215.186 as permitted sender) 
smtp.mailfrom=hel...@googlegroups.com
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 of hel...@googlegroups.com 
designates 209.85.215.186 as permitted sender) 
smtp.mailfrom=hel...@googlegroups.com

---

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 of hel...@googlegroups.com 
designates 209.85.222.184 as permitted sender) 
smtp.mailfrom=hel...@googlegroups.com;
        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 of hel...@googlegroups.com 
designates 209.85.222.184 as permitted sender) 
smtp.mailfrom=hel...@googlegroups.com

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 ofm...@opensmtpd.org  designates 
45.76.46.201 as permitted sender)smtp.mailfrom=misc@opensmtpd.org
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 ofm...@opensmtpd.org  designates 
45.76.46.201 as permitted sender)smtp.mailfrom=misc@opensmtpd.org
---

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 ofgil...@gmail.com  designates 
209.85.128.45 as permitted sender)smtp.mailfrom=gil...@gmail.com
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 ofgil...@gmail.com  designates 
209.85.128.42 as permitted sender)smtp.mailfrom=gil...@gmail.com

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 <r...@mrstuudio.ee <mailto:r...@mrstuudio.ee>> 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
    <opensm...@list.imperialat.at
    <mailto:opensm...@list.imperialat.at>> 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 notificat...@facebookmail.com
        <mailto:notificat...@facebookmail.com>
        > designates 66.220.144.215 as permitted sender)
        > smtp.mailfrom=notificat...@facebookmail.com
        <mailto:notificat...@facebookmail.com>
        >
        > 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.
        >
        > Thanks,
        > Reio
        >
        >






Reply via email to