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