> On 28. Dec 2023, at 19:22, Martijn van Duren <opensm...@list.imperialat.at> > wrote: > > On Thu, 2023-12-28 at 18:52 +0100, Kirill A. Korinsky wrote: >> >> >> 1. I'd like to report a small bug: OpenSMTPD injects header X-Spam: Yes when >> filter decided that it is junk, and this filter injects yes (in the lower >> case). Is it a bug? > > I'm not aware about any specific standard when it comes to this header. > smtpd has `strcasecmp(line, "x-spam: yes")` in mail.maildir.c, so the > capitalisation isn't important there. However, if you use smtpd with > filter-dnsbl as a filter before forwarding it to another server which > does check this header in a case-sensitive manner it would matter. > So unless you can point to a piece of software which checks it in a > specific capitalisation I don't see a direct reason to fix it.
Neither do I. Example of software is sieve: as far as I know it doesn't support matching case insensitive strings. >> >> 2. Is it possible to add support of white list(s)? Let pass the message if >> it contains on that list and optionally adds X-Spam-DNSWL: Listed at ... >> header. > > I've thought about adding whitelist support, but it's tough... > The RFC is explicitly vague on how to interpret responses, so there's > no way to determine how a response it to be interpreted without > extensive configuration either by the admin, or in the binary. > The latter would require in-depth knowledge of the different lists > on my end and actively maintain those, which I don't see myself doing. > > Another reason why I don't see myself supporting whitelists is because > I don't see their value. Mail is whitelist based in principle, so what > blocking feature is it supposed to overwrite and how is filter-dnsbl > supposed to do this? And that's not even starting on the prioritisation > of which list takes precedence. > > Do you have a specific use-case for whitelisting and if so, how would > you suggest to implement it in a generic way without making the filter > needlessly complicated? > > In short: I'm not against whitelists per se, but without the specific > use-case and a good plan of how to implement it without turning it > into a coding/admin nightmare I don't see it happening. I've read the code and I agree that implementing whitelist can be quite tricky. Anyway, I do have one idea: let introduce flag -i (inverse). It should remove X-Spam: yes if matches with -m. But I haven't see any easy way to implement it for non -m case. During read the code of this filter I guess I've found third point which I'd like to raise: filter fails in the case when one of provided DNSBL returns error. Shall it continue? -- wbr, Kirill
signature.asc
Description: Message signed with OpenPGP
