Re: filter-rspamd DKIM checks failing intermittently.

[Gilles Chehade]

On Wed, Oct 16, 2019 at 10:36:32PM +0300, Reio Remma wrote:
> So it's wasn't line breaks afterall.
> 
> It turned out that OpenSMTPD passes raw SMTP data lines to filters and raw
> SMTP lines have leading dot characters escaped by another dot, so .text
> became ..text. Feeding it to Rspamd like that made DKIM alignment tests
> fail, because body hash came out wrong.
> 
> A pull request has been submitted with a fix.
> 

nice catch :-)

-- 
Gilles Chehade @poolpOrg

https://www.poolp.orgpatreon: https://www.patreon.com/gilles

Re: filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

So it's wasn't line breaks afterall.

It turned out that OpenSMTPD passes raw SMTP data lines to filters and 
raw SMTP lines have leading dot characters escaped by another dot, so 
.text became ..text. Feeding it to Rspamd like that made DKIM alignment 
tests fail, because body hash came out wrong.


A pull request has been submitted with a fix.

This how seems to be a problem with Rspamd:

arc=reject (signature check failed: fail, {[1] = sig:google.com:reject});

Good luck,
Reio

On 13.10.2019 17:43, Reio Remma wrote:

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 ofhel...@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 ofhel...@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 ofhel...@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 ofhel...@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 > 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, 

Re: filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

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 > 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
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
;
>      dkim=fail (body hash did not verify)

Re: filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

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 of misc@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 of misc@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 of gil...@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 of gil...@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 > 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
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
;
>      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 
   sequence.
>
> Thanks,
> Reio
>
>

Re: filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

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

Re: filter-rspamd DKIM checks failing intermittently.

[Gilles Chehade]

Very likely yes, can you give it a try ?

On Sun, Oct 13, 2019, 15:15 Reio Remma  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 
>>sequence.
>> >
>> > Thanks,
>> > Reio
>> >
>> >
>>
>>
>
>

Re: filter-rspamd DKIM checks failing intermittently.

[Martijn van Duren]

On 10/13/19 3:05 PM, Gilles Chehade wrote:
> I don't think that is the issue,

I never said it's the issue in this particular case, I said that non-RFC
line-endings are most definitively an issue with DKIM and that clients
who send incorrect line-endings should be fixed.

> it is probably the filter-rspamd reconstruction of the message that is 
> incorrect.

I'm not familiar enough with filter-rspamd to know if that's the case.
> 
> On Sun, Oct 13, 2019, 15:00 Martijn van Duren  > 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 
>    sequence.
> >
> > Thanks,
> > Reio
> >
> >
> 

Re: filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

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

Re: filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

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?

Reio




On Sun, Oct 13, 2019, 15:00 Martijn van Duren 
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 ;
>      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 
   sequence.
>
> Thanks,
> Reio
>
>

Re: filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

On 13.10.2019 15:59, Martijn van Duren 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 
sequence.


I'm not sure Facebook will listen to me! :)

Reio

Re: filter-rspamd DKIM checks failing intermittently.

[Gilles Chehade]

I don't think that is the issue, it is probably the filter-rspamd
reconstruction of the message that is incorrect.

On Sun, Oct 13, 2019, 15:00 Martijn van Duren 
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 
>sequence.
> >
> > Thanks,
> > Reio
> >
> >
>
>

Re: filter-rspamd DKIM checks failing intermittently.

[Martijn van Duren]

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

filter-rspamd DKIM checks failing intermittently.

[Reio Remma]

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? :)

Thanks,
Reio