On Thu, 2023-12-28 at 22:40 +0100, Kirill A. Korinsky wrote:
> > On 28. Dec 2023, at 22:17, Martijn van Duren <opensm...@list.imperialat.at>
> > wrote:
> >
> > On Thu, 2023-12-28 at 20:05 +0100, Kirill A. Korinsky wrote:
> > >
> > > 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.
>
>
> Well, right now it should be written in sieve like this:
>
> > if anyof(header :is "X-Spam" "yes", header :is "X-Spam" "Yes") {
> > fileinto :create "Junk";
> > }
>
>
> a bit ugly but I agree that it's not enough for a release.
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".
>
>
> > >
> > > 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?
>
>
> Right now I'm making a kind of the experiment: living without any statistical
> analyser for my mail.
>
> The hypotesa: usual mail traffic for family mail server is too small to make
> statistical analyser like spamassasian useful by impact of mails.
>
> So, I'm testing another approach: only DNSBL which delivers everything that
> is matched into Junk folder.
>
> Long story short I do have the following configuration:
>
> - NiX Spam and blocklist.de at spamd
> - smptd configuration:
>
> > filter dnsbl proc-exec "filter-dnsbl -m \
> > all.spamrats.com \
> > bip.virusfree.cz \
> > bl.mailspike.org \
> > bl.spamcop.net \
> > bl.spameatingmonkey.net \
> > cbl.abuseat.org \
> > dnsbl-1.uceprotect.net \
> > dnsbl.dronebl.org \
> > mail-abuse.blacklist.jippg.org \
> > psbl.surriel.com \
> > rbl.0spam.org \
> > truncate.gbudb.net \
> > zen.spamhaus.org \
> > XXX.combined.mail.abusix.zone \
> > "
> >
> > filter dnswl proc-exec "filter-dnsbl -m \
> > XXX.white.mail.abusix.zone \
> > "
> >
> > filter "senderscore" proc-exec "filter-senderscore -junkBelow 70"
> >
> > listen on egress inet4 port smtp tls pki mx1.catap.net \
> > filter { "rdns", "fcrdns", dnsbl, dnswl, "senderscore" }
>
> - and sieve script to move mail:
>
> > if allof(
> > anyof(header :is "X-Spam" "yes", header :is "X-Spam" "Yes"),
> > not header :is "X-Spam-DNSBL" "Listed at white.mail.abusix.zone") {
> > fileinto :create "Junk";
> > }
>
> this works like a charm, really.
>
> 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
- Which option takes precedence in what situation
- Do we need to remove existing X-Spam headers?
- Are there other headers that need removing/modifying?
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.
>
> > >
> > > 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.
>
> 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.
>
> --
> wbr, Kirill
>
>
