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

Reply via email to