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.
>
> Thanks,
> Reio
>
>
