Very likely yes, can you give it a try ? On Sun, Oct 13, 2019, 15:15 Reio Remma <[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]> 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; >> > dkim=fail (body hash did not verify) header.d=facebookmail.com >> > header.s=s1024-2013-q3 header.b=pNWbKJUd; >> > dmarc=pass (policy=reject) header.from=facebookmail.com; >> > spf=pass (host.domain.com: domain of [email protected] >> > designates 66.220.144.215 as permitted sender) >> > [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. >> > >> > Thanks, >> > Reio >> > >> > >> >> > >
