> 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: https://github.com/OpenSMTPD/OpenSMTPD/blob/7.4.0p1/usr.sbin/smtpd/mail.maildir.c#L192-L196 but setup it as Yes, see: https://github.com/OpenSMTPD/OpenSMTPD/blob/7.4.0p1/usr.sbin/smtpd/smtp_session.c#L2772-L2773 >> 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
signature.asc
Description: Message signed with OpenPGP
