> 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 

Shall it continue?

wbr, Kirill

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to