Very likely yes, can you give it a try ?

On Sun, Oct 13, 2019, 15:15 Reio Remma <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> 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 notificat...@facebookmail.com
>> > designates 66.220.144.215 as permitted sender)
>> > smtp.mailfrom=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