On Thu, 2023-12-28 at 20:05 +0100, Kirill A. Korinsky wrote: > > 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.
Does this currently pose a problem for anyone? If not I don't see a reason to make a new release for it. > > > > > > > 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. Why? What does this bring? Why do you need this? > > 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? If a filter (or the intermediate DNS layer) returns an error we are in limbo. If we accept the mail, but it's listed we're probably delivering spam; if we reject the mail we're very likely to drop legit mail. Both are undesirable. Failing the message asking to try again later seems the safest option to me. > > -- > wbr, Kirill >
