> On 28. Dec 2023, at 23:34, Martijn van Duren <opensm...@list.imperialat.at> 
> wrote:
> I've never used sieve, but this already is a custom rule and not a
> X-Spam specific header check from sieve itself. However, a quick
> online search shows me the i;ascii-casemap comparator. Maybe you
> can give that a try.
> Also, smtpd.conf(5), from which I've taken the string, uses a lower
> case "yes".

Well... OpenSMTPD checks that value via strcasecmp to avoid case issue, see:

but setup it as Yes, see: 

>> The idea of both changes to use white lists to remove X-Spam: yes from both 
>> negative filters.
> The discussion about having a single whitelist overrule a whole sluice
> of lists apart. If you want whitelisting in filter-dnsbl it would
> require special handling of a whole range of different options:
> - Which response means what for what list

I assume any found response, like it works now with black listing.

> - Which option takes precedence in what situation

I assume that white list override the black one.

> - Do we need to remove existing X-Spam headers?

If we may do it in one run, we simple don't need to setup it.

> - Are there other headers that need removing/modifying?

I don't see any of this.

> This would make filter-dnsbl grow way beyond of what it was ever
> intended for into something where I'm afraid is not properly
> maintainable for both programmer and admin.
> Maybe you can write your own filter-dnswl with filter-dnsbl and
> filter-admdscrub as inspiration.

Or I may make a series of patch over your code. It seems not that complicated.

>>>> 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.
>> I see your point.
>> My point: user may wait messages and to be very nervous if it delayed for a 
>> while.
>> Important message means something like a ticket for a train in 5-15 minutes 
>> or something like that.
>> And here DNS seems like a single point of failure.
> Sure, but if I'm in a hurry and need a ticket I'm not going to rely on
> mail anyway. Either I'm going to buy it at the door, or I hope they have
> an option to download the ticket from the browser (which most of the
> ticket purchases I make have an option for). Only as a last resort I'm
> going to rely mail and just hope that everything works as it should.

Well, this is an example from the last week :)

If I haven't open DB application for a while, more than a month it had missed 
updated of so-called Deutschlandticket, and I wait the email with approval code 
to re-download it to the application.

I know that is edge case, but DNS failure is also edge case.

>> I think that it should be configurable by bypass DNS error by probability of 
>> delivering spam instead of delaying everything.
> Even as an option I'm not particularly fond of the idea... But if enough
> people think it's a worthwhile addition (you're the first one in 4 years
> to have raised this request) and the diff is small enough I might
> consider it.

From another hand, locally installed unbound should solve that issue on the 
first place.

wbr, Kirill

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to