Dne úterý 23. dubna 2019 12:48:08 CEST, Per Jessen napsal(a):
Carlos E. R. wrote:
On 23/04/2019 11.56, Per Jessen wrote:
Carlos E. R. wrote:
On 23/04/2019 09.55, Vojtěch Zeisek wrote:
Dne čtvrtek 18. dubna 2019 16:02:21 CEST, Per Jessen napsal(a):
Carlos E. R. wrote: > On 18/04/2019 14.36, Per Jessen wrote: >> Carlos E. R. wrote: >>> It says "DATE_IN_PAST", which is false, but that's (1). >>> I don't see why it is counting a score of 9.
Could this be related to possible wrong ntp/time zone/... configuration on either side?
Maybe, but spamassassin doesn't complain.
I would assume DATE_IN_PAST to be relative to current time. So any mail processed hours after it arrived will hit that one.
Date in the past can happen to an email that was delayed before sending. Delayed before hitting the first SMTP server, that is, not delayed in transit, which is not the fault of the person sending: that should hit another different rule indicating that the mail was delayed in transit. Ie, it is a check against the "Date:" header, and should compare to the date of the first relay, not of the recipient.
Yes you're right, that is exactly what SpamAssassin does. It has 4-5 rules, and they compare against the Received: headers. Maybe rspamd does it differently?
Otherwise, when the list has a hiccup and mail was delayed half a day, spamassassin would complain madly. I can verify that if wanted.
Perhaps not "complain madly", a 12 hour delay is about 1 point. Seems ot me we're back at BROKEN_HEADERS and asking the ISP to adjust the silly 10 point score for that rule? Vojtěch, any luck with that?
I pointed him to this discussion and all the resources, but he is still not convinced that problem is in rspamd or in his configuration. We don't observe any other 100% pattern, so can we rule out option, that problem is in some senders? Our conference? Prove it's rspamd's bug? Prove it's wrong server configuration? -- Vojtěch Zeisek Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/ https://trapa.cz/